2.5 KiB
name, description
| name | description |
|---|---|
| ship | 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". |
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. If commits have landed since, 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 (only if asked)
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.
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.