| name | check-code-review |
| description | Phase 6 code review — inspect a child-task diff across correctness, security, contract, scope, and clarity, and record tracked findings to evidence |
| metadata | {"layer":"review","tier":"judgment","delegates":[{"trigger":"review depth","to":"code-reviewer"}]} |
One-Liner
Find the real defects in this diff and record each as a tracked finding — presence of a review is
not the goal, a resolved finding list is.
Delegate craft depth to the expert. For broad-scope analysis (security classes, N+1, smells)
load the vendored code-reviewer (see
../../resources/expert-skills-map.md); this skill keeps the
dimensions, the tracked ## Review checklist, and the gate.
Run as a design-derived role. When invoked as the Phase 6 reviewer (via
check-review-loop), the reviewing agent carries the role resolved by
scripts/role-resolver.sh --phase review (e.g. a Go Backend Tech Lead, loading its expertise
chain) and its verdict is recorded with harness review open/record so the review-provenance-gate
proves an independent review ran on this diff. See
../../resources/phase-roles.md.
Core Philosophy
A review that produces prose but no tracked findings is theatre: nothing forces resolution. Record
findings as checkboxes so the review-fix-gate can hold verify until each is fixed or consciously
accepted. Review the diff, not the whole repo — scope creep dilutes attention.
Review dimensions (apply each; details in references/)
- Correctness — logic, edge cases, error handling, off-by-one, null/empty, concurrency.
- Security — input validation, injection, authz, secrets in code/logs, unsafe deserialization
(deep pass: check-security-review when auth/data/external).
- Contract fidelity — matches
docs/design/api.md + schema; no silent behavior drift.
- Scope — change stays inside the child-task (WIP=1); flag creep as a separate feature.
- Reuse/clarity — duplication, needless complexity (deep cleanup →
check-refactor).
Workflow
Phase 1 — Context
State the diff's intent in one sentence. Gate: if you cannot, ask the author before reviewing.
Phase 2 — Inspect
Walk the diff against each dimension above + references/review-checklist.md. Note critical issues
immediately, don't wait. Gate: every changed file has been read.
Phase 3 — Record (tracked checklist)
Write findings to evidence ## Review as checkboxes — resolution is durable and gate-checkable:
- [ ] <finding> (file:line, severity) # open
- [x] <finding> (file:line) — fixed
- [x] <finding> — (accepted: <reason>)
If genuinely clean, write No issues found with a one-line justification of what was checked.
Gate: every finding has a file:line + severity; nothing vague.
Examples (Bad vs Good)
for u in users: orders = Order.objects.filter(user=u)
users = User.objects.prefetch_related("orders").all()
More patterns: references/common-issues.md.
Reference Guide (load on demand)
| Topic | Reference | Load when |
|---|
| Review checklist | references/review-checklist.md | starting a review |
| Common issues (Bad/Good) | references/common-issues.md | spotting recurring defects |
| Report template | references/report-template.md | writing the ## Review block |
Gates & loop
quality-gate needs a ## Review section; review-gate rejects placeholders; review-fix-gate
blocks verify while any - [ ] is open. This skill is one pass — run it inside
check-review-loop (independent reviewer + capped fix→re-review).
Use the strong tier; never downgrade a review to save tokens
(../../resources/token-budget.md). Persona: Non-Technical gets
plain-language findings, Developer gets the full list (../../resources/persona-mode.md).
