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.

.gitignore

@@ -0,0 +1 @@
+/synced/

bro/SKILL.md

@@ -1,7 +1,6 @@
 ---
 name: bro
-description: Restate the last message in plain human language, with no jargon.
+description: Restate the last message in plain human language, with no jargon. Use only when Harry explicitly asks for it ("/bro", "bro this", "recap /bro"), never on your own initiative.
-disable-model-invocation: true
 ---
 
 Restate your last message. Stop using jargon and speak coherently. State it more simply and concisely, like one human talking to another.

google-developer-style/SKILL.md

@@ -1,167 +0,0 @@
----
-name: google-developer-style
-description: Use for all technical writing, including user responses, documentation, README files, tutorials, procedures, API references, code comments, release notes, commit messages, pull request descriptions, issue descriptions, reviews, and technical plans. Applies the Google developer documentation style guide with British English spelling.
----
-
-# Google developer style
-
-Use the [Google developer documentation style guide](https://developers.google.com/style)
-for all technical writing. This requirement includes short responses, not only formal
-documentation.
-
-## Precedence
-
-Apply guidance in this order:
-
-1. Follow explicit instructions from the user.
-2. Follow project-specific terminology, templates, and writing requirements.
-3. Follow this skill.
-4. Consult the current Google guide when this skill does not answer a style question.
-
-Depart from the guide when doing so makes the content more accurate, clear, consistent,
-or appropriate for its readers. Apply one deliberate exception throughout the text:
-use British English spelling instead of American English spelling. For example, use
-_behaviour_, _customise_, _organisation_, and _licence_ as appropriate. Do not change
-code, API names, quoted text, product names, commands, file paths, or established
-project terminology to British spelling.
-
-## Core principles
-
-- Put the reader's goal and the important result first.
-- Write for a technical reader who might be in a hurry.
-- Be clear, concise, accurate, and consistent.
-- Use a conversational, friendly, and respectful tone without slang or frivolity.
-- Prefer familiar, precise words. Remove filler, jargon, buzzwords, clichés, and
-  culturally specific references.
-- Preserve necessary technical detail. Define unfamiliar terms and abbreviations at
-  first use.
-- Write for a global audience. Avoid idioms, humour that depends on culture, and
-  figurative or directional language.
-- Use inclusive and accessible language. Do not describe tasks as easy, simple, quick,
-  obvious, or trivial.
-- Make claims specific and supportable. Avoid superlatives, marketing language, and
-  promises about unreleased features.
-- Keep content timeless where practical. Avoid phrases such as _currently_, _at this
-  time_, and _new_ when a concrete version or date is more useful.
-
-## Voice and grammar
-
-- Address the reader as _you_. Do not use _we_ to mean the reader or _let's_ to give an
-  instruction.
-- Use active voice and name the actor when it is not clear.
-- Use present tense for current behaviour and imperative verbs for instructions.
-- Put conditions and context before the action: "If the build fails, inspect the log."
-- Put the purpose before the action when it helps: "To validate the file, run..."
-- Keep sentences focused on one main idea. Split long or heavily qualified sentences.
-- Use contractions when they sound natural and do not create ambiguity.
-- Use the serial comma.
-- Avoid exclamation marks, semicolons where a full stop works, excessive parentheses,
-  and unnecessary dashes.
-- Do not use _please_ in instructions or placeholder phrases such as _please note_.
-- Do not make software anthropomorphic. State what a system or component does.
-
-## Structure
-
-- Use the smallest structure that makes the content easy to scan. Do not add headings,
-  summaries, or lists to short content without a clear need.
-- Use sentence case for titles and headings.
-- Start each section with useful information, not a restatement of its heading.
-- Keep paragraphs short and focused. Put one topic in each paragraph.
-- Use numbered lists for ordered steps and bulleted lists for unordered items.
-- Make list items grammatically parallel. Introduce a list when the context is not clear.
-- Use descriptive link text that explains the destination. Do not use "click here" or
-  expose a URL when a useful label is available.
-- Use unambiguous dates. Include the year when readers might need it.
-- Provide alt text for meaningful images. Do not rely only on colour, position, or shape
-  to communicate information.
-
-## Procedures
-
-- State prerequisites and required context before the steps.
-- Prefer the shortest accessible procedure that completes the task. Do not document
-  several equivalent methods unless readers need them.
-- Use one numbered step for each substantial action. Use a bullet for a single-step
-  procedure.
-- Begin each step with an imperative verb and use complete sentences.
-- State where the reader performs an action before stating the action.
-- Write actions in the order in which the reader performs them.
-- Put `Optional:` at the start of an optional step.
-- State an action before its result or justification.
-- Explain placeholders immediately after the command that contains them.
-- Avoid "run the following command". State what the command accomplishes.
-- Do not use _above_, _below_, _left_, or _right_ to locate content or controls.
-
-## Technical formatting
-
-- Use backticks for filenames, paths, commands, flags, environment variables, code
-  elements, literal values, HTTP methods and status codes, console output in prose, and
-  text that the reader enters.
-- Use fenced code blocks with a language identifier for multiline code or commands.
-- Use bold only for UI elements and short run-in headings. If a UI value is code, use
-  bold and code formatting together.
-- Use italics sparingly for introduced terms or semantic emphasis. Do not underline
-  text except through link rendering.
-- Preserve the exact spelling and capitalisation of code symbols, products, and UI
-  labels.
-- Use all-capital descriptive placeholders such as `PROJECT_ID`. Explain each
-  placeholder.
-- Do not turn code elements into English verbs or inflect them. Write "send a `POST`
-  request", not "`POST` the data".
-- Refer to an HTTP value as a status code, for example, HTTP `404 Not Found` status code.
-- Give code samples enough context to run, use realistic but safe values, and keep them
-  focused on the point being explained.
-
-## Content-specific guidance
-
-For responses:
-
-- Answer the question directly. Include only context that helps the reader act or decide.
-- Report facts, changes, verification, limitations, and next steps precisely.
-- Do not add generic acknowledgements, conclusions, or offers of more help.
-
-For pull requests and commits:
-
-- Use an imperative, specific title that describes the outcome.
-- Explain the problem, the material change, and how it was verified.
-- Separate motivation from implementation detail. Mention risks or follow-up work only
-  when they are concrete.
-- Do not reproduce the diff or use promotional language.
-
-For issues and bug reports:
-
-- Use an outcome- or symptom-focused title.
-- Include the observed behaviour, expected behaviour, reproduction steps, relevant
-  environment, and evidence when available.
-- Distinguish facts from hypotheses. Do not present an unverified cause as certain.
-- State acceptance criteria as observable outcomes.
-
-For reviews:
-
-- Lead with actionable findings ordered by severity.
-- Identify the location, consequence, and required correction.
-- Use direct, respectful language. Critique the change, not the author.
-- Do not dilute concrete findings with generic praise or low-value style comments.
-
-For reference documentation:
-
-- Describe what an API element does in present tense.
-- State requirements, defaults, ranges, units, side effects, errors, and return values
-  explicitly.
-- Use consistent terminology and parallel descriptions across related elements.
-
-## Final check
-
-Before sending or publishing technical writing, check that it:
-
-- Answers the reader's likely question first.
-- Uses British English spelling outside literal or official names.
-- Uses active voice, present tense, and second person where appropriate.
-- Removes filler, vague claims, repeated context, and unnecessary structure.
-- Formats code, UI labels, links, lists, and headings consistently.
-- Gives procedures in executable order with prerequisites and placeholders explained.
-- Separates verified facts from assumptions.
-- Remains accurate when read without hidden conversational context.
-
-For a question not covered here, consult the relevant page in the current
-[Google developer documentation style guide](https://developers.google.com/style),
-then apply the British English spelling exception.

implement/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: implement
+description: Do a piece of work on its own branch, open a PR, and run `review-loop` until it is GREEN, then hand Harry the verdict. Use when Harry says "/implement", "do this in a PR and review-loop it", "make a PR and get it green". Never merges or ships.
+---
+
+# Implement
+
+Takes a task from "do this" to a GREEN PR without Harry having to drive each step. It ends at GREEN. Shipping is a separate step under the `ship` skill, and only when Harry says so.
+
+## 1. Set up
+
+- Work in a fresh worktree off the latest base branch. In Patterm, use `worktree.create`. Elsewhere, follow the repo's branch convention.
+- If the task needs a product or design decision you can't make from the request, the code or the repo's docs, ask before writing code. Otherwise, start.
+
+## 2. Build it
+
+- Make the smallest change that does the task well. Add or update tests for what you change.
+- Run the checks the repo's AGENTS.md lists, and fix what fails.
+- If the task turns out much bigger than it looked, or needs a different approach than the one Harry named, stop and tell him before carrying on.
+
+## 3. Open the PR
+
+Don't ask whether to commit or open the PR. That is the point of this skill.
+
+- Commit, push the branch, and open the PR with the remote's own tool.
+- Start the PR description with one plain sentence on what it solves. Follow it with how you tested it.
+- In Patterm, attach the PR URL to your session with `reference.attach`.
+
+## 4. Review until GREEN
+
+Run `review-loop` on the PR, with yourself as the implementer. Use the reviewers Harry named, or Smartypants if he named none. Let its rules on scope, round limits and stopping for Harry apply as written.
+
+## 5. Report
+
+When the loop ends, send Harry the `review-loop` verdict and the PR link. If the PR is GREEN, say it's ready to ship. Leave the worktree and branch in place for `ship`.
+
+If a parent agent started you, send the verdict with `report_to_parent` and leave relaying to Harry to the parent.
+
+## Boundaries
+
+- Never merge, approve or close the PR, even when it's GREEN. If Harry also asked to ship, the `ship` skill does that after this one ends.
+- No production writes, deploys or changes to live services.
+- Commit only to the task's branch, never to main.

review-loop/SKILL.md

@@ -0,0 +1,71 @@
+---
+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"), and as the review step of `implement`. 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 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;
+   - 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 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|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.
+- Reviewers never write code. Only the implementer does.
+- Leave the reviewers open until the loop ends, then close them.

ship/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: ship
+description: Merge a reviewed PR once Harry has explicitly said to, update the local main checkout, clean up what the task created, and watch the rollout if he asks or the repo says shipping includes it. Use for "merge it", "ship it", "merged, monitor the rollout", "clean up and get main up to date".
+---
+
+# Ship
+
+Merging, building and deploying are separate steps. Do only the ones Harry asked for, and say which ones happened.
+
+## 1. Merge (only on explicit authorisation)
+
+Merge only when Harry has said "merge it", "ship it" or similar about this PR in this conversation. A conditional instruction such as "merge it if it's green" counts once the condition is met. A GREEN review on its own does not. If he says he merged it himself, skip to step 2.
+
+Before merging, check:
+- the PR head is the SHA that was reviewed. One exception: a merge of the base branch into the PR whose conflict fixes were purely mechanical (imports, lockfile, CHANGELOG, generated files), with checks passing afterwards. That merge is fine; mention it in the report. If any other commits have landed, or resolving a conflict meant changing logic, tell Harry and stop;
+- the latest review is GREEN, or Harry accepted the remaining findings;
+- CI passes and the PR is mergeable.
+
+If any check fails, report it and stop. Merge with the remote's own tool (`gh`, `tea`, or the provider MCP) and follow the repo's merge style. If the repo's AGENTS.md or memory describes how merges work there, follow it.
+
+## 2. Update main
+
+In the main checkout, fetch and fast-forward main (`git merge --ff-only`). If that would not fast-forward, or the checkout has local changes, stop and say so. If the lockfile changed, reinstall dependencies the way the repo does.
+
+## 3. Clean up what this task created
+
+Remove only things this task owns:
+- the worktree, if no other session is linked to it and it has no uncommitted or unpushed work;
+- the local branch, once its commits are in main;
+- the PR's reviewer and implementer agents and dev servers, once they have reported.
+
+Anything else, such as other agents' worktrees or older branches, needs a list for Harry, not removal.
+
+## 4. Watch the rollout (if asked, or if the repo requires it)
+
+Watch when Harry asks, or when the repo's AGENTS.md says shipping includes monitoring. In that case, don't ask first. A merge is not a deploy. Find out how this repo deploys, from AGENTS.md, CI config or memory. Watch that deploy until it finishes, then check the signals that matter for the change, such as errors, job success and the metric it was meant to move. Use read-only access.
+
+Report: deployed or not, at which SHA, what you checked, and anything that looks wrong. If something looks wrong, report it and suggest a fix or revert. Don't act on it yourself.
+
+## 5. Finish
+
+Send one report:
+- what merged, at which SHA;
+- whether it deployed;
+- what you cleaned up;
+- anything still running, with an estimate.
+
+During a long watch, send a line at each milestone, and straight away if an estimate passes. Once nothing is left for this task, call `request_close`.
+
+## Boundaries
+
+- No production writes, migrations, backfills, canaries, flag or percentage changes, or config changes unless Harry approves that exact action.
+- Don't deploy or restart live services as part of shipping, unless Harry asks for it separately.

traffic-light-review/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: traffic-light-review
+description: Code review returned as a traffic light GREEN / YELLOW / RED for mergeability.
+---
+
+When performing a code review on a pull request or a requested commit, you should return your findings in a RED / YELLOW / GREEN format.
+
+**RED**: There are problems with this code that should block deployment.
+**YELLOW**: The code could be deployed as-is, but there are some issues that should probably be resolved first, such as mildly inefficient query patterns (highly inefficient would be RED) or documentation inconsistencies.
+**GREEN**: Merge recommended.