ship

name	ship
description	Use when the user explicitly invokes /ship or asks whether finished BDC, code, docs, or release work is ready to ship, publish, merge, or close out.
when_to_use	Use after work is implemented and verified. Do not use for normal coding steps, early planning, or simple Q&A. If the user says 别走流程, 直接做, 简单点, or 不走地图, skip this skill unless release safety is genuinely at stake.
argument-hint	[--allow-large]
user-invocable	true
allowed-tools	["Bash"]

/ship — Local-First Release Gate

Step 0: Escape Hatch

If the user says 别走流程, 直接做, 简单点, or 不走地图, do not force /ship. Acknowledge once and do the smallest direct action.

Exception: do not bypass safety gates for deploy, public upload, database migration, force push, destructive writes, or secret exposure.

Step 0.5: Project Goal Check

If PROJECT_GOAL.md exists in the project root, read it before GO/NO-GO. If the package conflicts with current_phase, exit_criteria, or out_of_scope, return NO-GO unless the owner explicitly accepts the conflict.

Contract

Decide whether the current work is ready to ship. /ship is local-first: it does not assume GitHub, PRs, remote pushes, or public release unless the project workflow requires them.

Process

1. Determine project type and workflow:
   • local BDC / docs / config
   • app or package
   • GitHub PR / publish / deploy workflow
2. Gather evidence:
   • current git status and diff stat
   • plan status if plan-driven
   • latest /verify verdict if present
   • whether latest /verify verdict includes Verified HEAD: <short-sha> matching current HEAD
   • latest test/lint/health evidence
3. For BDC changes:
   • default: run or require /health --quick
   • broader local confidence: run or require /health --baseline
   • do not bypass /health by directly invoking health internals
4. Apply size and intent gate.
5. Return GO / NO-GO with rollback or restore plan.

Verify Freshness Gate

/ship consumes /verify; it does not re-run code/test/security fan-out by default.

For non-trivial code, BDC behavior, release, merge, publish, or deploy work:

1. Get current HEAD with git rev-parse --short HEAD when inside a git repository.
2. Find the latest /verify verdict in the current context or a project-local verify marker if one exists.
3. Require that verdict to include Verified HEAD: <short-sha> matching current HEAD.
4. If no matching verdict exists, return NO-GO and make the next action run /verify or /verify --deep.
5. If the latest matching verdict is REQUEST_CHANGES, return NO-GO and point to its blockers.

Escape phrases such as 别走流程, 直接做, 简单点, or 不走地图 do not bypass this gate for deploy, public upload, database migration, force push, destructive writes, secret exposure, or release decisions.

Size and Intent Gate

• ~100 lines changed: good.
• ~300 lines changed: acceptable if it is one logical change.
• >600 lines changed: default NO-GO for PR, publish, merge, or release unless mostly mechanical deletion, generated output, or automated codemod.
• One ship package should contain one feature, one bug fix, or one refactor intent.
• Feature + broad refactor must split unless the refactor is a local supporting cleanup.
• --allow-large or explicit user instruction can override the size gate, but the reason must be recorded.

Output

Verdict: GO | NO-GO
Scope:
Evidence:
Blockers:
Risks accepted:
Rollback / restore plan:
Next action:

Verification

• The output includes GO or NO-GO.
• The output includes evidence, blockers, risks accepted, and rollback / restore plan.
• BDC work uses /health --quick by default and does not call health baseline internals directly.
• Non-trivial work either cites a fresh /verify verdict for current HEAD or returns NO-GO.

Red Flags

• The package mixes broad refactor and new behavior.
• Diff size exceeds 600 lines for PR/publish/merge without explicit override.
• The release depends on a rollback plan that has not been stated.
• The latest /verify verdict is stale because HEAD changed after review.

Common Rationalizations

Rationalization	Response
"Tests passed, so ship it."	Do not. Incident: standards/debugging.md 2026-04-04 says written rules decayed until hooks/review gates enforced them; ship needs evidence plus risk/rollback judgment.
"It is local BDC work, so no release gate is needed."	Advisory false. BDC readiness still needs fresh health, release, privacy, and smoke evidence before any public claim.

Anti-patterns

• Do not treat "tests passed" as "ready to ship". Because: release readiness also needs scope, risk, and rollback judgment.
• Do not create a PR for local-only BDC work by default. Because: this repo is often operated as a local synced BDC.
• Do not call health baseline scripts directly from /ship. Because: /health is the user-facing health entrypoint and owns the health evidence contract.
• Do not re-run code-reviewer, test-engineer, or security-auditor inside /ship by default. Because: /verify owns quality fan-out; /ship owns release judgment.