skills/review-loop/SKILL.md

name, description

name	description
review-loop	Get a pull request reviewed by Patterm reviewer agents, send their findings to whoever is fixing it, re-review with the same reviewers, and give Harry one traffic-light verdict. Use when Harry asks for reviews ("get fable and smartypants to review it", "traffic light review via patterm", "iterate until green"). Never merges.

Review loop

Runs review rounds on one PR until it is GREEN or Harry has to decide something. It uses the traffic-light-review skill as the rubric.

Start

1. Pin the head: record the PR URL, base branch and exact head SHA. Every review round names that SHA, so nobody reviews a moving branch.
2. Pick reviewers: use the ones Harry named. If he named none, use harness_presets, ask which to use, and wait for his answer. Don't add reviewers he didn't ask for.
3. Spawn each reviewer with spawn_agent and that preset. Tell them:
   • the PR, base, head SHA and worktree path;
   • read-only: no edits, commits, pushes, merges or PR comments;
   • apply traffic-light-review and back every finding with a file and line;
   • judge the PR against what it set out to do, and list ideas beyond that as follow-ups, not findings;
   • report_to_parent with the verdict and findings.
4. Wait with timer_fire_when_reported_all on the reviewer IDs. Don't poll output.
5. Note the PR's diff size (files and lines changed). You'll compare against it later.

Keep the PR the size it started

Reviewers always find more to suggest. A loop that acts on every suggestion turns a small PR into a large one that is harder to review and riskier to ship. So:

• Fix bugs, regressions and missing tests for what the PR changes. These are the point of the loop.
• Send anything else to follow-ups, such as refactors, new abstractions, extra options, or tidying code the PR didn't touch. A follow-up becomes a todo or a line in the verdict, not a change to this PR.
• Ask the implementer for the smallest fix that resolves each finding.
• If the diff has grown well beyond where it started (roughly half again), stop and tell Harry before going further. He may prefer to split the PR.

This doesn't mean ignoring real problems to keep the diff small. A correct fix that needs more code is fine. The test is whether a change is needed for this PR to be right.

Each round

1. Read each report and check every finding against the code yourself. Drop the ones that are wrong, and say why. Move out-of-scope ones to follow-ups.
2. Write one verdict for Harry (format below).
3. GREEN: stop and report. Merging is Harry's call, or use ship if he has already authorised it.
4. RED or YELLOW with clear fixes: send the confirmed findings to the implementer, meaning whichever agent owns the branch, or yourself if you wrote it. If it has already reported, send_message it and wait for its report.
5. After the fixes, pin the new head SHA. Then send_message the same reviewers: give them the new SHA and the findings they raised, and ask them to check those fixes and anything new. Reuse the reviewers because they keep their context. Spawn a replacement only if a reviewer's process is gone. If that happens, give the replacement the earlier findings.
6. Stop and ask Harry when a fix needs a product or design decision, when reviewers disagree on something that matters, or after three rounds without reaching GREEN.

Verdict format

<GREEN|YELLOW|RED> — PR #<n> @ <short SHA>
Reviewers: <name: verdict>, …
Must fix: <finding, file:line> (or "none")
Should fix: …
Dismissed: <finding — why>
Follow-ups: <out-of-scope suggestion> (not in this PR)
Diff: <files/lines now> (started at <files/lines>)
Needs you: <decision> (only if there is one)

Keep it short. Harry wants the answer, not the transcripts.

Boundaries

• Never merge, approve or close the PR.
• Reviewers never write code. Only the implementer does.
• Leave the reviewers open until the loop ends, then close them.