review

Review and verification

Combine problem discovery and the evidence checking of completion claims into a single review. The review scope comes from the user's request; WIP can be reported as findings — implementation does not have to be finished before review.

Process

1. Clarify the diff/version under review, the target behavior, and the required acceptance. Examine the relevant source code, tests, documentation, and existing evidence; do not substitute the implementer's explanation for inspection. Also search the repo for every file that documents how code should be written and list them as the standards sources: CODING_STANDARDS.md and CONTRIBUTING.md are mandatory whenever they exist, plus lint/format convention notes, ADRs for the area touched, and CONTEXT.md terms; skip rules that tooling already enforces.
2. Check correctness, contracts, boundaries, and regressions along concrete failure paths; check conventions against the standards sources, code changes always layer on the smell baseline in references/smell-baseline.md (it applies even when the repo documents nothing; docs-only changes skip it). A documented repo standard wins and suppresses any smell it endorses; a smell is always a judgement call ("possible Feature Envy"), never a hard violation, listed as Minor by default and never blocking. Important risks warrant deep investigation; there is no need to pad findings or run a fixed number of review rounds.
3. When independent inspection adds value and the runtime allows it, use a read-only subagent with a clear scope; when dispatching several review axes (e.g. a standards axis and a contract/correctness axis), issue them together in one message, in the foreground, and aggregate their reports side by side without merging or reranking; the absence of a subagent is not itself a failure. If the user or the project explicitly requires independent review, honestly flag it when that condition is unmet. When the environment has external delegation skills such as cli-delegate, a read-only independent re-check across model CLIs is allowed; its result is a claim, and the evidence still returns to the main tree for re-verification.
4. Map the required criteria to pass / fail / unknown. fresh evidence means the evidence still applies to the current relevant code, configuration, and inputs; actual outputs unaffected by subsequent changes can be reused, and do not automatically expire because the skill changed or a commit already exists. A completion claim counts as evidence only via the actual output of runnable checks; implementer paraphrase or verbal assertion does not count.
5. Only fill in missing or invalidated checks. Use cold re-verification according to evidence ambiguity and risk; do not require delegating another agent to re-run the same tests.
6. Judge the specific completion claim: ready is possible only when there are no unresolved blocking issues and all required criteria pass. Critical/Important correctness, data, permission, or contract issues must all be resolved; list non-blocking suggestions separately. Do not delete or alter tests or acceptance scripts in order to pass; if the acceptance contract genuinely must change, get the user's consent first.
7. Persist findings (conditionally): all findings handled on the spot → do not persist to disk. If there are findings pending across sessions and the project has a recovery surface → write to this track's state surface: state.md Evidence records the findings list (number/location/severity) and the ready verdict, and Next records the pending fixes; when findings are numerous or need independent tracking, persist to docs/reviews/YYYY-MM-DD--<topic>-review.md, linked from this track's row or from state. Projects without a recovery surface keep in-session handoff and create no new state files.