stefan-stepzero shipkit-ship — Build to Done
Purpose: The consumer-facing BUILD entry point. Takes a plan
(.shipkit/plans/) and drives it to a confirmed, ground-truth completion bar.
shipkit-ship is a thin caller. It does not implement its own build loop — it states the what (steps + bar) and hands off to the engine, which owns the how (partition → fan-out → reconcile → integrate → stop-at-bar). This is Shipkit-native drive-to-done: one engine, one completion contract.
Read first: install/shared/references/core-automation.md — the contract the engine
runs. This skill only assembles the call.
What it does
Invoke shipkit-orchestrate in autonomous mode over the plan. Nothing more —
the engine runs inline in the main session, launches the parallel build, reconciles
against ground truth, integrates serially, and stops at the bar.
Pass the engine the four inputs (calling interface in
install/skills/shipkit-orchestrate/SKILL.md):
| Input | For a build |
|---|---|
| steps | the plan's phases / file-ownership clusters, in dependency order — the units to build (from .shipkit/plans/<feature>.json) |
| bar | the ground-truth completion criteria (below) — stated explicitly; the engine advances only when they are true on disk / in git |
| mode | autonomous (build runs unattended to the bar) — add the scale toggle for very large / long builds |
| elicitive | normally none — a build should run with the spec/plan already resolved. If a step genuinely needs a human decision, mark it elicitive so the engine bubbles it (never inside a workflow), rather than letting a worker guess. |
The bar (state it — don't let a worker self-report "done")
A build is done only when all of these are reconciled (verified, not reported):
- Functional surface complete — every element the no-gaps spec named across the four dimensions (applications / datastores / contracts / integrations) is built, not just the happy path. A frontend that implies a backend has the backend.
- Plan acceptance met — every acceptance criterion / phase gate in the plan passes.
- Tests green — the plan's named checks (tests, build, lint) pass.
- Integrated — work is committed, rebased onto the target branch, and landed per the integration policy (serial, one lane at a time, never forced past unverified work).
The engine reconciles each against git + disk artifacts each round and re-dispatches
gaps until the bar is met or the slot ceiling hits (then it reports done-vs-outstanding
— no silent truncation).
Before running
The engine confirms (via AskUserQuestion) the things a build must not assume: the
bar, the target branch, the integration policy (stage-for-review vs
auto-merge), and the slot ceiling. shipkit-ship supplies the bar above as the
default; the rest are confirmed at run start.
When this skill integrates with others
Before this skill
/shipkit-spec→/shipkit-plan— a spec (with the no-gaps gate passed) and a plan must exist; the plan is the build's step list and the spec's named surface is the bar.
What it calls
/shipkit-orchestrate— the engine (autonomous mode). All dispatch / reconcile / integrate lives there, once.
After Completion
The engine has driven the plan to the bar (or reported done-vs-outstanding at the slot
ceiling); run-state is in <runDir>/orchestration.json.
Next: Run /shipkit-review-shipping — post-build review runs as the engine in
steered mode, one unit per app-area / screen (frontend + backend), surfacing findings
to the user to steer.
Context files this skill reads
.shipkit/plans/<feature>.json— the plan (the steps).shipkit/specs/**— the spec's named functional surface (the bar)
Context files this skill writes
- None directly — the engine owns run-state (
<runDir>/orchestration.json) and verification output perinstall/shared/references/run-artifacts.md.
Remember: shipkit-ship is one engine call. Its whole job is to name the bar and
delegate. "Done" means reconciled against ground truth — not the 80% that looks finished.