Ship

Ship — the close-out chain

The hand-typed ritual (align → wrapup → commit → push → "did it deploy?") as one command. Invoking /ship is the owner's commit-and-push authorization — do not ask again before committing or pushing; that consent is the point of the skill. Ask only when something is genuinely wrong (a conflict, a failed push, a red scan the owner should see before publishing).

Run the chain in order; each link is cheap. Determine <plugin-root> as usual (${CLAUDE_PLUGIN_ROOT}, global config plugins/rad-repo-manager, or local workspace plugins/rad-repo-manager).

1. Align-lite — mechanical scans only

PLUGIN_ROOT=$( [ -d "./plugins/rad-repo-manager" ] && echo "./plugins/rad-repo-manager" || echo "${CLAUDE_PLUGIN_ROOT:-$HOME/.gemini/config/plugins/rad-repo-manager}" )
python3 "$PLUGIN_ROOT/scripts/repo-scan.py" . --json --no-record
python3 "$PLUGIN_ROOT/scripts/doc-freshness.py" . --json
python3 "$PLUGIN_ROOT/scripts/structure-drift.py" . --json

(python on Windows; skip silently if Python is unavailable.) No judgment passes, no proposals, no fixes — this is a smoke check, not repo-align. Red findings go into the final report as one line each — for architecture/api staleness and structure drift, name the specific delta ("api.md: 3 undocumented routes"), and include the align cadence when commits_since_align ≥ 25; nothing here blocks the ship unless the owner says so.

2. Quick wrapup

Run the quick path of /rad-repo-manager:wrapup inline: overwrite docs/handoff.md (≤60 lines) from git evidence, carry the ## Deferred — do not re-raise section forward, ask the two questions (decisions settled? → append docs/decisions.md; lessons? → append docs/lessons.md). This is the only interactive moment on a green ship.

3. Reviewed staging

git status --short
git diff --stat
git diff
git add -- <reviewed-path-1> <reviewed-path-2>
git diff --cached --name-status
git diff --cached --stat

Never use git add -A. Stage only paths verified as part of the requested change. Use git add -u -- <reviewed-paths> for reviewed deletions. If staged paths differ from the intended set, or unresolved conflicts/unrelated changes are present, stop.

4. Pre-ship repository contract gate

python3 "$PLUGIN_ROOT/scripts/pre_ship.py" . --run-validation --json

(python on Windows.) This gate inspects staged Git blobs rather than the working tree and blocks protected paths, likely secrets, unexpected generated output, oversized files, failed validation commands, or source changes without declared validation. Commands come from applicable root/scoped AGENTS.md files and optional .rad-repo-manager.json scope rules.

Unstaged changes to any repository contract file always block validation. A staged contract change also blocks by default; after reviewing that staged diff explicitly, rerun with --allow-contract-change. Never use that flag for an unstaged contract. Do not commit or push while any finding remains.

5. Commit — conventional message

git commit -m "<type>(<scope>): <summary from the staged diff>"

Use conventional-commit style (feat:, fix:, docs:, chore:…), grounded in git diff --cached, with one commit. Use the user's message hint if supplied. If the tree is clean and the handoff did not change, skip commit+push and say so.

6. Push

git push origin main

If the current branch isn't main, push the current branch and say so plainly — don't silently merge or switch branches. If the push is rejected (diverged), stop and surface it; never force-push.

7. Deploy-verify — only when declared

Read AGENTS.md for a deploy: line. No deploy: target (or deploy: none) → skip this step silently.

When a target is declared (e.g. deploy: coolify):

• If the rad-coolify-orchestrator MCP tools are available, poll the deployment (coolify_list_running_deployments / coolify_get_deployment for the app) until it reports live or failed — report the outcome before asking the owner to test anything.
• If the MCP tools are not available (not installed, not authenticated, or a non-Coolify target with no tooling), degrade gracefully: say plainly "pushed — deploy target <target> declared but I can't verify it from here; check it manually" and move on. Never claim a deploy succeeded that you did not observe.

8. Stray branch / worktree sweep

git branch --merged main
git worktree list

Report merged local branches and leftover worktrees; delete only on the owner's one-word OK (deletion is the one irreversible act in the chain, so it stays gated).

9. One-line report

Shipped: <commit hash> pushed to origin/main · deploy <live/failed/skipped/unverified> · handoff fresh · <N> scan note(s) · <N> stray branch(es)

Anything yellow/red from step 1 gets one extra line each, pointing at repo-align.

What this skill does NOT do

• No deep alignment pass, no doc filing, no reconcile — mechanical scans only (that's repo-align / wrapup --full).
• Never force-pushes, never merges branches, never deletes branches/worktrees without the owner's explicit OK.
• Never stages unreviewed paths or bypasses a pre-ship finding.
• Never claims a deploy result it didn't observe.
• On the first /ship in a repo whose AGENTS.md has no fit-out record: run the fit-out step first (<plugin-root>/references/fit-out.md) — detect traits, propose the equipment menu once, install what's approved, then continue the chain.

References

• <plugin-root>/references/shelf-spec.md — budgets, Deferred ledger, entry formats
• <plugin-root>/references/fit-out.md — trait detection + equipment menu (first ship)