Custom Context

A diff on its own only tells the reviewer what lines changed — not what calls the changed function, what the surrounding contract is, or what the original task required. CloudAEye enriches a review with context from three sources: a code-context graph, ticket bodies (Jira / GitHub), and per-call context fields. All are optional; the review degrades gracefully when they are absent.

Code-context graph

When your repository is connected to CloudAEye, the review is aware of more than the diff: it accounts for call sites and blast radius beyond the changed lines, so findings and descriptions can reason about end-to-end wiring rather than isolated hunks.

The baseline is your project's main branch — the one you selected when you integrated the repository with CloudAEye. Your pending change is compared against the current state of that branch, so the review reflects the code your change will actually merge into.

• Repository connected → the review is context-aware.
• Not connected → the review falls back to diff-only analysis. Everything still works; findings are just less precise on blast radius.

Context enrichment is best-effort: if it can't be applied for a change, the review still runs.

Ticket resolution (Check Task)

/check_task can judge the diff against a ticket rather than pasted text. The ticket is resolved on every call, so live comment threads flow into the verification. - GitHub issues - Jira tickets - .txt, .md files saved locally.

The intent field

Distinct from context, every call carries a one-paragraph intent string describing the change the agent just made. It is the primary steering signal for the review and — for Inspect — the only channel for asking the reviewer to leave a prior finding alone.