# Ship > Stage ⑤ Ship master orchestrator — the release stage after Verify. ship-preflight 必跑串行 (release-readiness gate) → 委派 PR/deploy 给 gstack /ship → publish 留 publish.yml CI (tag push 触发)。schema_version: harnessed.workflow.v3 with delegates_to (1 sub: preflight serial order 1) + disciplines_applied (6 default) + tools_available (release-preflight + ship + planning-with-files)。Triggered by `/ship` (bare per ADR 0030) or `harnessed ship` after `harnessed verify`. Deploy boundary = TAG-READY (no push/publish/tag). - Skill: `easyinplay/ship` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add easyinplay/ship` - Raw SKILL.md: https://api.skillmd.com/api/skills/easyinplay/ship/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: easyinplay (https://skillmd.com/u/easyinplay) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/easyinplay/ship --- # ship master orchestrator (v3) — Stage ⑤ ## Overview The 5th stage, after Verify. harnessed has the pieces (a release-preflight gate, gstack `/ship`, `publish.yml` CI) — this master orchestrates them into one repeatable release path, the way comet (archive), Trellis (finish-work), and Claude-Harness (`/harness-release`) each close their loop. | order/mode | sub | when fires | | ---------- | --- | ---------- | | 1 (serial) | `preflight` | always when stage=='ship' — read-only release-readiness gate | After preflight passes, the master delegates PR + deploy to gstack `/ship` (composition — harnessed does not reimplement it), and the actual `npm publish` + GitHub release happen in `publish.yml` CI on tag push. ## Process 1. **preflight (always)** — run `harnessed release-preflight`. If any check fails (most often an empty `## [Unreleased]`), STOP and document the release / clean the tree first. 2. **PR / deploy (delegate)** — invoke gstack `/ship` for PR creation + pre-land review. 3. **publish (CI)** — push the `v` tag (with explicit user approval) → `publish.yml` runs `npm publish` + creates the GitHub release. ## Boundary (important) This stage stops at **tag-ready**. It never pushes to the remote, never publishes to npm, and never creates a git tag on its own. Those are CI + explicit-approval actions, by design — "PR ready != release ready", and "release ready != already published". ## How to invoke !`harnessed checkpoint intent ship` > The banner above (when present) means this invocation is REGISTERED with the engine (an intent marker) — not yet compliant: steps 2-3 below seed the ledger, and a per-turn `` reminder persists until they run. The numbered sequence below **is** the state machine — execute it step by step with Bash. Do NOT improvise an equivalent flow from the Overview above: freelancing bypasses the engine (no per-sub ledger, no evidence guard, no recovery). harnessed is the orchestration brain (`harnessed gates` says which subs fire, `harnessed prompt` gives each spawn-ready prompt, `harnessed checkpoint` records the ledger); YOU spawn with CC-native Task / Agent tools. Do NOT pipe to `harnessed run ship` — that is the CI/headless path (in-process SDK spawn that blocks the session, bypasses Agent Teams, and hangs inside Claude Code). 1. If the clarification criteria fire for "$ARGUMENTS" (≥2 approaches / core algorithm / API contract / high error cost), clarify interactively in THIS session first (AskUserQuestion) and lock decisions; otherwise transparent-skip. Produce a locked spec. 1b. Bash: `harnessed facts ship --out .harnessed-facts.json` → it lists ONLY the facts this stage’s gates actually read: deterministic ones already filled (change size / files touched / stage, from git), judgement calls left `null` with a one-line hint of what to judge. Edit the file and replace each `null` in `facts` with your honest answer from the locked spec — leave one null only if you genuinely cannot judge it (it then falls back to the built-in default). Do NOT skip this step and do NOT invent facts the command did not ask for. 2. Bash: `harnessed gates ship --task "" --context-file .harnessed-facts.json --skip-sub discuss` → parse the JSON `{fire, skip, parallelism}`. This is the plan SoT (no spawn). Keep the verbatim JSON. 3. Bash: `harnessed checkpoint start ship --plan ''` → seeds the per-sub ledger so `harnessed status --recover` can re-orient you after compaction. 4. If `parallelism.escalate_to_teams === true`: read `~/.claude/rules/agent-teams.md`, then drive the fired subs as an Agent Team. There is NO create step and no create tool — spawn one background teammate per fired sub with `Agent(name: , run_in_background: true, prompt: ` prompt>)` and the team forms implicitly on the FIRST spawn, with this session as lead (the `team_name` input is accepted but ignored — the name is session-derived). Coordinate via `SendMessage`; when a sub is finished, ask that teammate to shut down BY NAME (e.g. "ask the verify-qa teammate to shut down"). Still checkpoint each sub (`complete` / `fail`) as below. 5. Otherwise, for each fired sub in `order` (serial subs sequentially, parallel subs concurrently): - **If the entry has `is_master: true`** (a stage master — e.g. `/auto` firing `plan`/`task`/`verify`): do NOT prompt+spawn it. RECURSE: run that master’s own `harnessed facts --out .harnessed-facts.json` (fill the nulls) → `harnessed gates --task "" --context-file .harnessed-facts.json --skip-sub discuss` → `harnessed checkpoint start --plan ''` → repeat this loop for ITS fired subs. - **Else (leaf sub):** a. Bash: `harnessed prompt --task "" --json` → parse `{prompt, max_iterations, model}`. b. Spawn a CC-native subagent (Task / Agent tool) with that `prompt` and `model`, then drive delivery with harnessed's own completion gate: - on return, write the subagent's final output to a file and run `harnessed checkpoint complete --result-file ` — it is fail-closed on the declared artifacts, the TDD boundary, and the verbatim `COMPLETE`. - if it blocks, run `harnessed checkpoint fail --failing-tests ` to record the attempt; it prints BUDGET-EXHAUSTED / NO-PROGRESS / BREAK-LOOP when a stop condition is reached. - respawn ONLY while none of those three has fired. Any one of them means stop: re-scope the subtask, fix the blocker, or escalate to the user. Never respawn past a stop directive. c. If the output contains `STATUS: NEEDS_CLARIFICATION` + questions: STOP, relay them verbatim via AskUserQuestion, append the answers to the spec, then re-spawn the same sub. d. On `COMPLETE`: write the subagent’s final output to a file, then Bash `harnessed checkpoint complete --result-file --summary ""`. Fail-CLOSED — it blocks unless every declared `artifacts_expected` file exists, the TDD boundary passes (non-empty evidence / both the red and green sides present / the test file was not deleted), and the result carries a verbatim `COMPLETE` (or a structured COMPLETE status). `--result ` is the inline variant; `--result-file` wins and is quoting-safe on Windows. On a non-zero exit the sub is NOT done — re-spawn to close the gap, or pass `--force` only to deliberately override (records `evidence_status=overridden`, an audited override rather than a silent pass). e. If the complete gate blocked: Bash `harnessed checkpoint fail --failing-tests ` to record the attempt (omit the flag when the sub has no tests — the evidence-artifact digest is the fallback progress metric). It prints `BUDGET-EXHAUSTED` (attempts spent vs `workflows/defaults.yaml ralph_max_iterations`), `NO-PROGRESS` (no improvement for N consecutive attempts) or `BREAK-LOOP` (this sub failed >= the threshold) once a stop condition is reached. Respawn ONLY while none of those three has fired; any one of them means STOP — re-scope, fix the blocker, or escalate to the user, and report it. 6. After all fired subs are `done` (or recorded `failed`), Bash `harnessed status --recover` to confirm the ledger and report a per-sub fired/skipped/done/failed summary to the user. **If you lose context (compaction / resume):** run `harnessed status --recover` first — it reads the ledger and prints "you are here, this is next" so you resume at the first `pending` sub instead of restarting. If the ledger is empty, re-run steps 2-3.