code-review-protocol

name	code-review-protocol
description	Code review protocol. Use when reviewing final diffs against .agents/PLAN.md.

Code Review Protocol

Review only concrete diffs and applicable plan requirements. Do not implement fixes.

Review target

Read .agents/PLAN.md, .agents/PROGRESS.md, and relevant .agents/HANDOFF.md before reviewing. Review the requested concrete diff; do not turn the review into a broad cleanup or refactoring pass. A finding must be introduced by the reviewed change unless the request explicitly includes pre-existing problems.

Every delegated code review is durable. Read .agents/REVIEW.md as the read-only schema and write the complete result only to the orchestrator-assigned absent .agents/REVIEW_code-<n>.md path. Never write findings to .agents/REVIEW.md, self-allocate, or overwrite artifacts.

A re-review receives a new successor artifact with predecessor/disposition references; it never edits its predecessor.

Check:

• Correctness.
• Plan compliance.
• Scope discipline.
• Error handling.
• Data and state consistency.
• Maintainability.
• Test coverage.

Finding criteria

Report only discrete, actionable problems that the author would likely fix. A finding must have a demonstrated effect on correctness, security, performance, reliability, or maintainability; identify the affected scenario, input, or caller rather than speculate. Do not report style nits, formatting, generic refactoring, or intentional behavior changes.

Use one finding per problem. Point to the shortest useful changed line or range, normally one line and rarely more than 5–10 lines. Keep each comment to one concise paragraph, explain why it fails and when, and state the needed fix when useful. Findings are ordered P0 through P3.

Priority definitions

• [P0]: Drop everything to fix. A universal release, operations, or major-usage blocker that does not depend on input assumptions.
• [P1]: Urgent. Fix in the next cycle.
• [P2]: Normal. Fix eventually.
• [P3]: Low. Nice to have.

Do not emit numeric or JSON priorities.

Output format

Write the full templates/REVIEW.md schema to the assigned artifact. Use exactly this shape for every finding:

### F1 — [P1] Short imperative title

File: `/absolute/path/to/file.ext:123`

Comment: One concise paragraph explaining why this is an issue, including the scenario/input where it occurs and the needed fix when useful.

• Keep titles under 80 characters.
• The file reference is required and must use an absolute path with the shortest useful line or :start-end range.
• If there are no findings, write No findings.

After the findings, include:

## Overall Correctness

Patch is correct

One to three sentences explaining the verdict.

Use exactly Patch is correct or Patch is incorrect. A patch is correct only when existing code and tests will not break and the patch is free of bugs and other blocking issues. Any correctness bug, including a [P1] or [P2] finding, makes the patch incorrect; non-blocking style, formatting, documentation, and other nits do not. Use the durable artifact's owner, status, plan-compliance, and routing sections. A re-review writes the next assigned code artifact and references predecessor dispositions; it never edits its predecessor. Chat returns only path, verdict, and blocking status.

Review artifact rules

• Use review types from templates/REVIEW.md: plan, code, security, performance, migration, or test review.
• Use finding statuses open, accepted, resolved, deferred, wont-fix, and blocked.
• Route required fixes by <artifact-path>#F<n> through .agents/PROGRESS.md section 6. Issues / Routing when requested, preserving the finding's [P0]–[P3] priority without copying its comment.