auto-ship

name	auto-ship
version	0.1.1
description	Take verified work to shippable — autonomously, with fail-closed gates and a human sign-off on anything irreversible. It runs the pre-launch gate (final validate green, review clean, security/observability/ rollback checks), and a gate that DIDN'T actually run is treated as a blocker, never as clean. Then it prepares the release: atomic commits, a changelog/release notes grounded in the actual changes, version bump, docs for user-visible/API changes — and opens the PR (or stages the rollout: feature flag + rollback path + monitoring). The deploy itself is gated on explicit human approval. It fails closed and never fabricates a green gate to ship. This is the SHIP phase. Composes adversarial-verify (confirm the "ready" claim), checkpoint-resume, and budget-guard.
allowed-tools	["Bash","Read","Write","Edit","Grep","Glob","Agent","AskUserQuestion","Workflow"]
disable-model-invocation	true
user-invocable	true
effort	high
argument-hint	[what to ship — a branch/feature] (default: the current branch)
arguments	["target"]
hooks	{"PreToolUse":[{"matcher":"Bash","hooks":[{"type":"command","command":"for p in \"${CLAUDE_PLUGIN_ROOT:-/nonexistent}/auto-ship/scripts/guard-ship-irreversibles.sh\" \\\n \"${CLAUDE_PROJECT_DIR:-.}/.claude/skills/auto-ship/scripts/guard-ship-irreversibles.sh\" \\\n \"${CLAUDE_PROJECT_DIR:-.}/.agents/skills/auto-ship/scripts/guard-ship-irreversibles.sh\" \\\n \"$HOME/.claude/skills/auto-ship/scripts/guard-ship-irreversibles.sh\" \\\n \"$HOME/.agents/skills/auto-ship/scripts/guard-ship-irreversibles.sh\"; do\n [ -f \"$p\" ] && AUTO_GUARD_ALWAYS=1 exec bash \"$p\"\ndone; exit 0\n"}]}]}
when_to_use	Use when a change is built, tested, and reviewed and you want it prepared for release — gates run, release artifacts written, PR opened / rollout staged. Do NOT use to build or fix (auto-build) or to review (auto-review); and never let it perform an irreversible deploy without explicit human sign-off. It touches release/deploy surfaces — it is explicit-user-only.

Shipping is where fabricated-clean verdicts and skipped gates do real damage. Non-negotiable: 1. GATES FAIL CLOSED. A configured gate that did not actually run (final validate didn't execute, review was skipped, an audit died) is a BLOCKER, never "clean". "Ready to ship" means every gate ran and passed — not that some were skipped. 2. THE FINAL VALIDATE IS LOAD-BEARING. Run the whole-suite validate on the integrated release state; a red or unrun validate blocks the ship, full stop. "Should pass" is not a pass — run it, read the exit. 3. HUMAN SIGN-OFF ON IRREVERSIBLE STEPS. Deploys, destructive migrations, publishing a release, anything you can't cleanly roll back → STOP and get explicit approval. Preparing artifacts is autonomous; pulling the irreversible trigger is not. 4. ROLLBACK BEFORE ROLLOUT. Anything risky ships behind a rollback path (feature flag, revert plan, staged rollout, migration back-out). No rollback path → not ready. 5. RELEASE NOTES ARE GROUNDED. The changelog/notes describe the ACTUAL changes (from the diff/commits), not aspirational or invented ones. Never fabricate a clean verdict or a change that didn't happen. 6. FASTER IS SAFER, IN SMALL INCREMENTS. Prefer small, flagged, reversible releases over a big-bang deploy.

Auto Ship

Overview

Get a change from "verified" to "released" the disciplined way: run the pre-launch gate honestly (fail closed on anything that didn't run or didn't pass), assemble grounded release artifacts, open the PR or stage the rollout with a rollback path, and hand the irreversible deploy decision to a human. The value is a ship that's provably ready — not one that looks ready because gates were skipped.

Phase 0: Preflight — scope, state, gate the "ready" claim

• Resolve scope ($target — the current branch by default) and the changes to ship (diff + commits).
• Confirm the state: a clean tree on the right branch, the build's checkpoint (if from auto-build) shows no blocked/dep_blocked tasks.
• Open a checkpoint-resume run; declare the ship budget/escalation points with budget-guard.

Success criteria: the change set + branch are known; upstream build state is clean (or gaps noted).

Phase 1: The pre-launch gate (fail closed)

Run the standing readiness gate; a gate that didn't run or didn't pass is a BLOCKER:

• Final validate — the whole-suite typecheck+lint+test on the integrated state. RED or unrun → block.
• Review clean — confirmed-blocker findings from auto-review are resolved (or run it now). Open blockers → block.
• Security — untrusted input / auth / data handling reviewed; no exposed secrets; deps audited.
• Observability — logs/metrics/traces exist for the new critical paths (you can answer "is it working in prod?").
• Rollback — a rollback path exists for anything risky (flag, revert, staged rollout, migration back-out).
• Docs — user-visible/API changes documented; ADR recorded for notable decisions.

Use adversarial-verify on the aggregate "ready to ship" claim: skeptics try to find a gate that's green-in-name-only. Report each gate's real status (ran + passed / failed / didn't run).

Success criteria: every gate's true status is known; any unrun/failed gate is surfaced as a blocker, not hidden.

Phase 2: Prepare the release artifacts

With gates green, assemble the release (autonomous — no irreversible action yet):

• Atomic commits — clean, scoped commit history (already per-task from auto-build); no git add -A grab-bags.
• Version bump — per the project's scheme (semver); grounded in the change's nature (fix/feat/breaking).
• Changelog / release notes — generated from the ACTUAL commits/diff, user-facing and honest; breaking changes called out with migration notes.
• Docs — finalize any user/API docs the change requires.

Success criteria: version, changelog, and docs are prepared and grounded in the real changes.

Phase 3: Open the PR / stage the rollout — human-gated deploy

• PR path (default): push the branch and open a PR via gh with the generated title/body (summary, test evidence, gate results, rollback plan). This is safe/reversible — autonomous.
• Rollout path (if deploying): present the staged plan — feature flag first, incremental exposure, monitoring to watch, and the rollback trigger. The DEPLOY itself is gated: STOP and get explicit human sign-off (AskUserQuestion) before any irreversible step. After deploy (if approved), confirm the monitoring signal and keep the rollback ready.

Success criteria: the PR is open (or the rollout staged); no irreversible step taken without explicit approval; rollback is in place.

Phase 4: Report

Close the checkpoint and report: gate results (each ran+passed, or the blocker), release artifacts prepared, the PR link / rollout status, the rollback path, and anything awaiting human sign-off.

Success criteria: an honest ship report; nothing irreversible done unilaterally; blockers (if any) clearly listed.

Common Rationalizations

Rationalization	Reality
"Review was skipped but the code looks fine — ship it."	A skipped gate is a blocker, not a pass. Run it or don't call it ready.
"The validate will pass, no need to run it before shipping."	"Will pass" is not "passed". The final validate is load-bearing — run it and read the exit code.
"This deploy is low-risk, I'll just do it."	Irreversible steps need human sign-off regardless of your confidence. Prepare autonomously; deploy on approval.
"We can add the rollback plan later."	Later is after it broke. No rollback path means not ready to ship.
"I'll write nice release notes covering what we intended."	Notes describe what actually changed, from the diff — not intentions. Ground them.
"Big-bang deploy is simpler than a flag."	Big-bang maximizes blast radius. Small, flagged, reversible is faster to recover — which is safer.

Red Flags

• "Ready to ship" while a gate didn't actually run (validate/review/audit skipped but counted clean).
• A final validate that was assumed green, not executed.
• An irreversible deploy/migration/publish done without explicit sign-off.
• Risky change shipped with no rollback path.
• Release notes mentioning changes not in the diff (or omitting breaking changes).
• A grab-bag commit (git add -A) in the release history.

Enforcement (deterministic, not prose)

While this skill is active, a skill-scoped PreToolUse hook runs scripts/guard-ship-irreversibles.sh on every Bash call: plain git push --force (without --force-with-lease) and git push --delete are BLOCKED at the tool layer — the "human sign-off on irreversible steps" contract is enforced by machinery. The deploy itself remains human-gated by process (Phase 3).

Guardrails

• Never treat a skipped/unrun gate as clean; fail closed.
• Never call the final validate passed without running it.
• Never take an irreversible step (deploy/migrate/publish) without explicit human approval.
• Never ship risky change without a rollback path.
• Never write release notes that aren't grounded in the actual changes.
• Prefer small, flagged, reversible releases over big-bang.

When To Load References

• adversarial-verify (skill) — stress the aggregate "ready to ship" claim to catch green-in-name gates.
• auto-review (skill) — run/finish the review gate if it hasn't been.
• checkpoint-resume (skill) — durable ship-run state.
• budget-guard (skill) — the escalation contract for the human-gated deploy.

Output Contract

Report:

1. pre-launch gate — each gate's true status (ran+passed / failed / didn't run → blocker)
2. release artifacts — version bump, changelog/notes (grounded), docs
3. PR link or staged rollout plan + the rollback path
4. anything awaiting human sign-off (irreversible steps) and any remaining blockers