Custom Context¶
A diff on its own only says which lines changed — not what calls the changed function, what the surrounding contract is, or what the original task required. CloudAEye enriches a review from three sources: a code-context graph, ticket bodies, and an optional intent note from your coding agent.
All three are optional. The review degrades gracefully when they are absent, and always tells you when it did.
Code-context graph¶
When your repository is connected to CloudAEye, the review sees 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.
| State | What you get |
|---|---|
| Repository connected | Context-aware review, compared against the integrated baseline branch |
| Not connected | Diff-only analysis against local HEAD. Everything still runs; findings are less precise on blast radius |
The output prints base_source= on every run. base_source=head means the repository is not integrated under your tenant — that is the one-line tell, and it is worth checking before concluding a review missed something.
Context enrichment is best-effort throughout: if the graph cannot be refreshed for a change, the review still runs.
Ticket resolution¶
The Check Task command 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 rather than a snapshot taken once.
| Source | Form | Requires |
|---|---|---|
| GitHub issue | https://github.com/<owner>/<repo>/issues/<n>, or owner/repo#42 |
CloudAEye GitHub access |
| Jira ticket | BETA-5225, or a list like [BETA-5225, BETA-5223] |
Your tenant key, plus the CloudAEye Jira app installed for that tenant |
| Local file | A .txt or .md spec you pass the contents of |
Nothing |
| Freeform text | Any description, passed verbatim | Nothing |
When a reference cannot be resolved, the tool returns a structured error rather than a verdict. A task made only of ticket references surfaces that error; a task that also carries prose proceeds against the prose and says which references were not checked. A verdict never silently implies an unfetched ticket was verified.
The intent field¶
intent is an optional one-line note on what just changed. Your coding agent writes it — you never have to. It has just done the work, so it describes it better than you would from memory.
Leaving it empty is fine; the review runs on the diff either way. When it is there, it steers what the reviewer prioritises, and on a re-run it is how the agent says which findings it already addressed — which is what stops the next pass repeating itself.