Code Review

Code Review

Review a completed code change, or an implementation plan before code exists, against the request or settled design with a reviewer set sized to the actual target. This is the canonical review method after every implementation route, and for a plan that descends from a settled design.

Each reviewer's read-only evidence and findings contract comes from the individual method it composes: code-review-method for reviewer-code-*, plan-review for reviewer-plan-*. This parent skill owns dispatch and synthesis. During review, do not edit target implementation files or dispatch implementers. Complete and synthesize the review first. A review-only request ends with the report. Only when review is part of an already-authorized implementation task, leave review mode afterward, fix valid findings, and run the narrowest verification that proves each correction.

Reviewer dispatch is mandatory for every nontrivial target. A trivial target shrinks the set to one reviewer, never to zero.

Determine the review target

1. Read the request or settled design. Record required behavior, non-goals, constraints, acceptance criteria, and applicable project context paths. Find the authorities that bind the change: read the root instructions file and the instructions file or README nearest to each changed path, and follow each authority they name for the changed area. Skip a document marked superseded or draft. Record the binding authorities as project context paths. When the repository names none, the request or settled design is the only intent source; search no further. If no intent source exists, report that blocker instead of inventing intent. The target is a first draft: the implementation recorded where it deviated from the plan or assignment, and the dispatching agent revises it into the design after this review. Reviewers therefore check the draft against the design as well as for defects and classify each recorded deviation and each discrepancy as consistent with the design or as drift, with evidence. Reviewers report; the dispatching agent decides acceptance.
2. Get the actual diff. A directory listing, file list, or implementation report is not a diff. When branch diff data is unavailable or includes unrelated concurrent work, use the current task's tracked changed files and tool write evidence, and state that limitation. For a plan target, read the complete plan instead.
3. Read changed files where hunks hide context. Trace changed public surfaces through callers, imports, registrations, and tests. Inspect deletions for live paths whose logic disappeared rather than moved.
4. Apply elegance-review-principles first and throughout. Additional specialist reviewers add constraints; they do not replace this method, severity model, or result contract.
5. List the target's material factual claims verbatim with their locations: version pins, artifact-content assertions, registry or feed availability, live-route statements, tool and file existence, and runtime-behavior premises the target depends on. Assign each claim to at least one reviewer. Every claim ends with one verdict from the reviewer protocol's vocabulary, and the result states exactly what the evidence supports.