requesting-code-review

name	requesting-code-review
description	Use independent review at meaningful semantic or risk boundaries and before substantive whole-change closeout.

Requesting Code Review

Purpose

Independent review supplies a perspective that implementation reports cannot. Place it where it changes confidence in semantic behavior, integration, or risk; do not manufacture a review merely to find a style issue or demonstrate process.

Low-risk mechanical work does not always need an independent reviewer by default.

When review is warranted

Request independent review at meaningful semantic or risk boundaries, including user-visible behavior changes, API or compatibility boundaries, cross-module integration, and substantive implementation milestones. Request a final whole-change review for substantive work so the reviewer can assess the joined behavior rather than isolated diffs alone.

Short changes still merit independent review when they involve security, data-integrity, permission, concurrency, or cross-module behavior. Repeated low-risk mechanical changes that follow an already-reviewed pattern may be reviewed as a group, with the chosen semantic acceptance evidence preserved.

Review inputs and scope

Give the reviewer the smallest durable package that permits real judgment:

• the requirement or task brief and binding constraints;
• the implementer report as evidence to inspect, not authority to trust;
• a review package for the exact commit range; and
• the semantic scenario, acceptance evidence, integration boundary, and named risks that warrant the review.

Ask the reviewer to judge semantic behavior and integration: whether the change solves the intended user or operational problem, preserves its contracts, and works with neighboring modules. Style and maintainability findings matter when they threaten that behavior or future safe change; they are not a quota.

Acting on findings

Fix Critical and Important findings before relying on the reviewed behavior. Record Minor findings when they have a clear owner or future decision. If a reviewer is wrong, respond with concrete code or semantic evidence rather than silencing the review.

After a fix, request another independent review only when the finding or fix changes semantic behavior, risk, or integration confidence. For a contained mechanical correction, preserve focused validation and the reason a further review would not add evidence.

Dispatch guidance

Use the active harness's supported worker mechanism; do not assume a particular subagent API. Select reviewer capability proportional to the diff's risk and the judgment required. Reviewers are read-only and should return evidence-backed findings with file references and severity tied to impact.

See code-reviewer.md for the whole-change review template.