harry
0d4de1a768
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.
54 lines
3.3 KiB
Markdown
54 lines
3.3 KiB
Markdown
---
|
|
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.
|