You asked for a skill that verifies, tests, previews, ships, and merges. Six of those already existed in ship-autonomous. Rather than fork the pipeline into a second skill that would drift, I added the three missing pieces to it: a verification gate before the commit, a merge gate after green, and a separate approval for deleting the branch.
The numbering is load-bearing — the skill runs these in strict order, and steps 6–8 are the standing policy it applies each time a PR event wakes the session. The two highlighted rows are new.
gh auth.origin/HEAD only if you're sitting on the default branch.commit-agent. A failing pre-commit hook stops the run — never --no-verify.pr-agent; captures the PR URL for everything downstream.This runs before the commit rather than after the PR opens, so a red test suite never becomes a public branch. Two parts, and the second one is conditional.
Detects the project's test* script from package.json and runs the
first match. Failure means the failing output verbatim and a full stop — no committing a
red tree, no interpreting the failure as someone else's problem. No test script at all is
reported out loud and the run continues.
Starts the dev server from .claude/launch.json, reads console and server logs
for errors, then screenshots the page at colorScheme: light and
colorScheme: dark. Theme-specific breakage gets fixed before the commit, not
after review catches it.
The condition matters: this step is skipped unless the change is actually observable in a browser. Your verification rule says not to start a server that can't prove anything, so a docs-only or plugin-only ship goes straight to the commit.
Merging is outward-facing and hard to undo, so it gets a re-check and an explicit ask. Checks can turn red between the last event and the merge, which is why the green state is confirmed again immediately beforehand rather than trusted from Step 7.
“Merge it” never authorizes --delete-branch.
Branch deletion is a second, separate approval. If you don't clearly say yes, the branch
stays.
This is in your global rules already, but a rule that lives only in judgment gets skipped under momentum — right after a merge succeeds is exactly when cleanup feels implied. Naming it as a step makes it a thing the skill has to do, not a thing it has to remember.
One more line went in at the end: a re-fired bot review on an already-approved PR isn't new information. After one substantive fix pass, only merge-blocking findings get actioned — the rest surfaces to you as a choice between merging and polishing.
Your request opened with “authors the change.” That isn't in the skill. A skill can't generically author arbitrary work — a step that says write the code is prose, not behavior, and it would trigger on every session that merely mentions shipping. The pipeline starts where there's a dirty working tree to ship, which is where the authoring has already happened.
Say the word if you want a scaffolding step in front of it, but I'd expect it to earn its keep as a separate skill rather than a preamble to this one.
| Path | Change |
|---|---|
| skills/ship-autonomous/SKILL.md | Added Steps 2.5 and 8, the bot-loop policy note, and the mcp__Claude_Browser__* preview tools to allowed-tools. Description now names verification and the gated merge. |
| .claude-plugin/marketplace.json | git-agent bumped 4.0.1 → 4.1.0. Minor: new behavior, nothing removed or renamed. |
| kit/plugins/git-agent/CHANGELOG.md | 4.1.0 entry under Added and Changed. |
Step numbering stops at 2.5 rather than renumbering 3–8 on purpose — the file cross-references its own step numbers, and a renumber would bury the actual change under a rename diff.