Add review-loop and ship skills

review-loop/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: review-loop
+description: 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.