User Guide¶

Five commands for reviewing your pending changes, once the plugin is installed. None of them edit your code — they report, you decide, Claude edits.

Command	Use it for
`/cloudaeye:inspect`	The routine bug check after finishing a task
`/cloudaeye:security`	The security surface on its own
`/cloudaeye:review`	Everything, before a significant PR
`/cloudaeye:implement`	A fix plan for findings a review produced
`/cloudaeye:check-task`	"Does this actually do what the ticket asked?"

What to review¶

/inspect, /security and /review all take the same optional argument.

/cloudaeye:inspect                    every uncommitted change
/cloudaeye:inspect src/auth/          only changes under that directory
/cloudaeye:inspect src/auth/login.ts  only that file
/cloudaeye:inspect #405               open pull request 405

Digits mean a pull request. For a directory actually named 405, write ./405.

Severity floor — add --critical, --high, --medium or --low to any of them:

/cloudaeye:review --critical
/cloudaeye:inspect src/auth/ --high

It's a floor, so --high reports high and critical. It also cuts cost: the floor reaches the scanner, not just the output, so lower-severity candidates are never worked up in the first place.

Severity is impact, not certainty:


Critical	Crashes, data loss, auth bypass, RCE, a leaked live credential
High	A wrong result on a real code path, a missing check with real impact
Medium	Degrades rather than breaks
Low	Style, naming, clarity

Two things to know¶

A scoped review only speaks for its scope. approve on src/auth/ means approved for that path. The report always names the scope and how many changed files it left out, and the cross-file checks can't see the excluded ones.

Pull requests must be open (drafts are fine), merge into your CloudAEye-integrated branch, not come from a fork, and change at most 50 files. You have to be standing in the repository the PR belongs to. Anything ineligible is refused up front with the reason.

The three review commands¶

/cloudaeye:inspect — bugs only: logic errors, compile breaks, edge cases, input validation, concurrency, error handling, clarity, naming, and signatures. No security prompts, so it's cheap enough to run after every task. If your change touches auth, untrusted input, secrets, crypto or LLM prompts, Claude will suggest /security rather than running it uninvited.

/cloudaeye:security — OWASP-style application security, plus the LLM, AI-agent and MCP surfaces, plus secrets on the changed lines. The extended types only attach to code that actually shows matching patterns, so running it on a repo with no LLM code costs about what a plain application-security pass would.

/cloudaeye:review — both of the above in one pass. The widest and most expensive; save it for a significant PR.

All three return a verdict (approve / request_changes) and a numbered list of findings with file, line, severity and category. Those numbers are what you use next.

`/cloudaeye:implement`¶

Turns findings into a fix plan. It never edits and never patches — it returns file, location, instruction, and the blast radius: the other call site with the same defect, the caller whose contract changes, the test that asserts on the old behaviour. That last part is the reason to use it over just asking Claude to fix things, which also works and costs nothing.

/cloudaeye:implement [1,3]                        by number
/cloudaeye:implement [2-4]                        a range
/cloudaeye:implement                              no list — all of them
/cloudaeye:implement [1,3] use a context manager  select two, constrain both
/cloudaeye:implement fix the 2nd point            plain words work too

Anything after the list becomes a hard constraint on every plan. A number that doesn't exist is an error naming the valid range, not a partial plan.

Some plans come back marked stale (the code moved since the review — it may already be fixed) or not_an_edit (no code change fixes it; a leaked credential needs rotating). If your request is ambiguous, nothing is planned and you're asked which you meant.

It doesn't work on a pull-request review — the plans describe edits to a working tree. Check the branch out locally and review again.

`/cloudaeye:check-task`¶

Checks the change against what was actually asked for.

/cloudaeye:check-task https://github.com/owner/repo/issues/42
/cloudaeye:check-task BETA-5225
/cloudaeye:check-task [BETA-5225, #42]
/cloudaeye:check-task the retry cap must be configurable, default 3
/cloudaeye:check-task                    reuses the task from last time

Issues and tickets are fetched fresh on every call, so new comments count. Freeform text is used verbatim — including text that merely mentions a ticket.

You get a per-requirement table (done / partial / not done), the gaps, anything out-of-scope you changed, and a verdict of DONE or NOT_DONE. The verdict is deliberately binary: a single partial requirement is NOT_DONE, because "mostly done" is how a half-finished task gets reported as finished.

ERROR means the check couldn't run — usually an unresolvable ticket. It's not a judgement on your change; paste the ticket body as text instead.

The loop¶

/cloudaeye:inspect          →  findings, numbered 1..N
/cloudaeye:implement [1,3]  →  fix plans   (optional)
Claude edits
/cloudaeye:inspect          →  confirms the fix landed, nothing new broke

Re-running resumes the same session while you haven't committed — you never hold a session id. Committing starts fresh, so iterate before you commit if you want the reviewer to keep the thread.

To tell the reviewer to leave a finding alone, say so when you ask for the re-review. That instruction is visible in what Claude sends, and the reviewer still checks every other finding against the real diff.

When output looks off¶

You see	What it means
`verdict: error`, or a `degraded` note	The review ran without your post-edit source. Not a clean review — re-run.
`context_refresh: skipped` / `failed`	The repository graph wasn't refreshed, so the answer rests on the diff alone. Usually an expired GitHub token, fixed server-side.
A very old baseline age	Your local `origin/<branch>` is stale — fetch before the next review.
`approve` with a `scope`	Approved for that path only.
"no findings at or above X"	There may be findings below your severity floor; the count is shown.

See Skills & Commands for what each command runs under the hood, and the Tool Reference if you are calling the MCP tools directly rather than through the plugin.