diff --git a/bro/SKILL.md b/bro/SKILL.md index b1701b7..9575d1d 100644 --- a/bro/SKILL.md +++ b/bro/SKILL.md @@ -1,7 +1,6 @@ --- name: bro -description: Restate the last message in plain human language, with no jargon. -disable-model-invocation: true +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. --- Restate your last message. Stop using jargon and speak coherently. State it more simply and concisely, like one human talking to another. diff --git a/implement/SKILL.md b/implement/SKILL.md new file mode 100644 index 0000000..d5c81bd --- /dev/null +++ b/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. diff --git a/review-loop/SKILL.md b/review-loop/SKILL.md index c25cbae..31ca6ba 100644 --- a/review-loop/SKILL.md +++ b/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. + ``` - — PR # @ + — PR # @ +Purpose: +Merge-ready: Reviewers: , … Must fix: (or "none") Should fix: … Dismissed: Follow-ups: (not in this PR) +Not verified: (or "none") Diff: (started at ) Needs you: (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. diff --git a/ship/SKILL.md b/ship/SKILL.md index b5a11e3..b29202d 100644 --- a/ship/SKILL.md +++ b/ship/SKILL.md @@ -1,6 +1,6 @@ --- 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. Use for "merge it", "ship it", "merged, monitor the rollout", "clean up and get main up to date". +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 @@ -12,7 +12,7 @@ Merging, building and deploying are separate steps. Do only the ones Harry asked 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. If commits have landed since, tell Harry and stop; +- 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. @@ -31,12 +31,22 @@ Remove only things this task owns: Anything else, such as other agents' worktrees or older branches, needs a list for Harry, not removal. -## 4. Watch the rollout (only if asked) +## 4. Watch the rollout (if asked, or if the repo requires it) -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. +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.