requesting-code-review

Requesting Code Review

Review completed work against its requirements before it cascades. Give the reviewer the work product and exact review range, never the whole session history.

Choose the path

Handle a standalone bounded read-only code review directly.

• For a user's standalone bounded read-only review, inspect and report it directly. Read only the named file and directly required context. Do not edit the code. Do not enumerate the workspace.
• For completed implementation work, dispatch a reviewer after a meaningful task, major feature, complex fix, or before merge.
• For one small file, use at most one reviewer unless its result lacks named evidence; explain the missing evidence to any follow-up reviewer.

For the direct path, format each finding as - <Severity>: <path>:<line> - <defect>. <impact and reasoning>. Use a plain path:line when a valid clickable absolute path is unavailable. Every finding must name the defect, impact, and reasoning. Never output a placeholder, empty link, or unfinished finding.

Define the review range

Prefer the base commit recorded before implementation. Otherwise derive it from the confirmed base branch:

BASE_SHA=$(git merge-base <base-branch> HEAD)
HEAD_SHA=$(git rev-parse HEAD)

Never default to HEAD~1; it silently omits earlier commits in a multi-commit task. On Windows, run these Bash commands in a Bash-capable shell or use their PowerShell equivalents.

Dispatch

Fill code-reviewer.md with:

• [DESCRIPTION]: concise summary of the completed work;
• [PLAN_OR_REQUIREMENTS]: authoritative behavior and constraints;
• [BASE_SHA] and [HEAD_SHA]: complete range to inspect.

Use the host's general-purpose worker or closest equivalent. Keep the review read-only and require exact file/line evidence, calibrated severity, reasoning, and a merge verdict.

Preserve and resolve findings

Maintain one accumulator of verified findings across every reviewer response. A later "no additional findings" must never erase an earlier verified issue.