Add implement skill; default review-loop to Smartypants and 5 rounds

review-loop: Smartypants when no reviewer is named, up to five rounds, a verdict with Purpose, Merge-ready and Not verified lines, and a one-line update after each round.
ship: allow a mechanical merge from base, watch the rollout when the repo requires it, and finish with one report and request_close.
implement: build on a branch, open the PR and review-loop it until GREEN. It never merges.
bro: agents can run it, but only when Harry asks.

review-loop/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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.
+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"), and as the review step of `implement`. Never merges.
 ---
 
 # Review loop
@@ -10,7 +10,7 @@ Runs review rounds on one PR until it is GREEN or Harry has to decide something.
 ## 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.
+2. Pick reviewers: use the ones Harry named. If he named none, use the Smartypants preset alone. Ask only if `harness_presets` has no Smartypants. 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;
@@ -38,23 +38,32 @@ This doesn't mean ignoring real problems to keep the diff small. A correct fix t
 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.
+6. Stop and ask Harry when a fix needs a product or design decision, when reviewers disagree on something that matters, or after five rounds without reaching GREEN. Stop sooner if a round repeats or disputes an earlier finding instead of finding less.
 
 ## Verdict format
 
+GREEN means the reviewers are GREEN, CI has passed and the PR merges cleanly. If CI is still running or the branch conflicts with its base, say "GREEN review" and give the reason in the Merge-ready line.
+
 ```
-<GREEN|YELLOW|RED> — PR #<n> @ <short SHA>
+<GREEN|GREEN review|YELLOW|RED> — PR #<n> @ <short SHA>
+Purpose: <one plain sentence: what this PR solves>
+Merge-ready: <yes | no: CI pending/failing, conflicts with base>
 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)
+Not verified: <assumptions a reviewer said it couldn't confirm> (or "none")
 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.
 
+## Keep Harry informed
+
+Don't make him ask for status. After each round, send a one-line update: round number, verdict, and what's happening next. If an estimate you gave passes, say so straight away along with the new estimate.
+
 ## Boundaries
 
 - Never merge, approve or close the PR.