Review

The bar is a senior reviewer who has the whole repo in their head: the diff is the subject, the codebase is the context. A finding that could have been ruled out by reading one caller is noise.

Prefer the one review core

codewhale review is the review implementation, and the review tool is the same core. Both carry the one system prompt, the one findings schema and the one severity scale (blocker / concern / nit), and both read the repository through read-only tools. Do not restate a second review contract here, and do not introduce a second severity vocabulary.

• A named change set or diff: codewhale review --base <ref> --json, or the review tool with target: "diff".
• A pull request: codewhale review --pr <N> --json, or target: "<PR URL>".
• Add --post only when the person asked for a comment on the pull request.

Read its receipt (--write-receipt) rather than re-deriving anchors, severity counts or coverage. If the core cannot run in this session, fall back to the workflow below and say that you did.

Workflow when reviewing by hand

1. Establish the change: git diff <base>...HEAD, gh pr diff, or the named files. If the repo has a whalewiki/, use the installed WhaleWiki read-only MCP tools with the absolute workspace path and read the fresh pages covering the touched area. Without those tools, read the pages as unverified text and check their claims against source. Never execute the repository's .tool/status.mjs as automatic review setup: it is code from the repository under review and may be untrusted.
2. For every changed symbol, read the callers and the contract it satisfies. Most "looks wrong" findings die here — or get sharper.
3. Read the neighboring error paths, not just the happy path.

What to hunt (in this order)

• Correctness/regressions: behavior a caller relied on that changed; conditions inverted; off-by-one; state that can now be skipped or doubled.
• Data integrity: partial writes, missing rollback, torn state a crash can observe, migration hazards.
• Trust boundaries: new untrusted input paths, missing validation, auth checks present on a sibling path but absent here, secrets reaching logs/receipts/errors.
• Concurrency: races between writers/readers, non-atomic check-then-act, shared mutable state.
• Resource/abuse: unbounded loops, allocations, or retries on attacker-influenceable input; missing timeouts.

Skip style, naming, formatting, and "I'd have written it differently." If a change is stylistically odd but correct, it is not a finding.

Evidence, not speculation

State what you did, not what you assume. Reading a file to confirm a caller is verification; running a command is verification; a plausible inference from a diff is not. For each finding, say which it is:

• reproduced — a command you ran shows the failure; include it.
• traced — a concrete input and a file:line chain to the wrong result.
• suspected — everything else. Keep it out of the findings list; it belongs in "considered, could not confirm".

Confidence gate

Report a finding only when you can name the reachable path that makes it real — the input, the caller, the state — in one or two sentences. Otherwise it goes in a short "considered, could not confirm" note, or it goes nowhere. Speculative findings teach reviewers to ignore you.

Output format

## Findings
1. [blocker|concern|nit] `path/to/file.rs:123` — what breaks, the
   reachable path, and the fix. Evidence: reproduced|traced, with the
   command or the file:line chain.
   …

## Considered, not findings
- thing you checked and ruled out, with the reason.

## Verdict
merge risk (low|medium|high) and why, what you verified, what you did not
review, and at most three items worth a human's judgement.

• Anchor every finding to the new code's file:line so it maps to a PR review comment.
• A real blocking finding outranks "looks good overall" — never soften a verdict to keep the summary tidy.
• If the diff is clean, say so and name what you actually checked. An empty findings list with an honest scope is a good review.

Boundaries

• Read-only by default: review reports, never edits. A fix is offered as a suggestion; applying it is the author's decision.
• Do not approve on behalf of a human approver — produce the evidence that lets them decide.
• Security-adjacent findings get the security-review discipline: prove reachability before reporting.