Review Bounded — Three-Round Bounded Code Review

Positioning

This skill is the orchestration layer of code review; it does not re-implement the execution details:

• Execution uses the agent's own tools (git, file reads, Bash) and the project's existing tests / lint / static checks;
• Each round executes the built-in instructions in references/round-prompt.md directly — no external services and no delegation to other review skills.

When to use / when not to use

• Use: feature branch development is complete and ready to merge; the user asks for "three rounds of CR" / "bounded review" / "check whether it converges" / "don't review forever".
• Don't use: single-line or pure-docs changes (one round is enough); the user explicitly asks for a quick single round; the user asks to review someone else's PR (this skill only reviews the current workspace/branch); non-interactive modes (-p / CI) — the per-round authorization and the commit decision require a human in the loop.

Workflow

1. Initialize
   - Read references/rubric.md (the severity scale; must be loaded before round 1 and governs all later rounds);
   - Ask the user to pick the review scope. Typical options:
   a. Current code vs the base branch (main, or master if absent): git diff $(git merge-base <base> HEAD) — the branch's own changes including staged and unstaged (merge-base keeps the diff clean even if the base has advanced);
   b. Uncommitted changes only: git diff HEAD — the default when working directly on the base branch;
   c. The current branch's recent commits: git log <base>..HEAD — the user specifies the range (e.g., the last N commits); per-round re-reads use git diff <base>...HEAD (three-dot: same merge-base semantics as option a, so the diff stays clean even if the base has advanced) for that range, and uncommitted changes on top of the range are out of scope unless the user includes them;
   d. Custom — the user names the scope in their own words (e.g., "only src/ and tests/", "the auth refactor in commit abc123", "everything changed this week"); translate it into a concrete diff, file list, or commit range before reviewing.
   - If the chosen scope turns out empty, report it and re-confirm the scope with the user.

2. Three-round loop (each round executes the full instructions in references/round-prompt.md)
   Each round = restate the previous rounds' finding lists (confirm memory, calibrate dedupe) → define the round scope and re-read the project's latest code → review against the rubric → report findings and ask for authorization → fix after authorization (changes stay in the working tree, no commits) → regression check (run tests/lint and record evidence) → record the round's conclusion (in the conversation).

3. Final output
   Per references/decision-rules.md: summarize the three rounds' findings and fixes, answer the three meta-questions, state the case against merging first, then give the CONVERGED / NOT CONVERGED verdict, the production-impact grading of the last round's issues, and the list of unresolved items; then show the three rounds' fix lists and let the user decide whether and how to commit (one commit or grouped by finding).

Recording

• All round records live in the conversation; no extra files are produced;
• For archiving, create a summary document only when the user says "write the conclusions to a file" (suggested: REVIEW.md in the repo root).

Hard rules

• Each round must re-read the project's latest code (git diff + file reads); reconstructing the code state from memory is forbidden.
• Every finding is graded on the rubric; the scale must not drift between rounds.
• Cross-round dedupe: re-reporting a previous round's issue in different wording is not a new finding.
• Findings without evidence are not reported; "no regression" without evidence is not written.
• Authorization must be obtained before fixing.
• No commits during the three rounds; afterward the user decides whether and how to commit.
• When unsure whether it converged, always judge NOT CONVERGED.
• The final verdict must be preceded by the case against merging (the strongest reasons not to merge).
• Output in the user's conversation language, detected from the user's messages (Chinese user → the Chinese template in references/decision-rules.md → "Output language"; English user → the English template).
• No agent-private features (hooks, slash-command syntax) — keeps the skill portable across agents.

Related files

• references/rubric.md — severity scale and review categories (read before round 1)
• references/round-prompt.md — per-round review instruction template (read each round)
• references/decision-rules.md — convergence rules after round three (read in the final phase)