Docs · Getting started

From install to merged PR.

shipd runs inside your coding-agent session as a plugin, backed by an LLM-free spec engine. Four steps to your first spec-driven change.

1

Install

The installer runs a doctor check — it verifies every prerequisite and prints the exact command to fix anything missing. It refuses to run half-configured.

$ curl -fsSL https://shipd.now/install | sh
✓ doctor: all prerequisites present
✓ plugin installed — skills available as /s:<name>
2

Plan — converge on the spec

State your intent. shipd investigates the codebase first, asks only what it genuinely can't answer, and emits the lean artifact set: plan.md, delta specs, tasks.md. Then it stops — you review the spec, not a diff.

/s:plan retries drop the idempotency key on checkout
→ .shipd/planned/checkout-retries/ · status: draft
3

Build — gated, refuted, merged

The context gate must pass before implementation begins. The orchestrator delegates to execution agents; the validator tries to refute every scenario; CI and semantic review gate the merge. The change archives and its deltas join the capability library.

/s:build
gate: PASS → 4 tasks → refute: confirmed → PR #212 merged
4

Watch the board

The shipd CLI fronts the engine's read verbs — no raw script paths, JSON-first output for tooling.

shipd listin-flight changes across the root and its worktrees
shipd status [change]a change's status and progress
shipd epic <slug>an epic's status, metadata, and member states
shipd boardthe interactive delivery board, full-screen
shipd metricsdelivery metrics
shipd lint [change]structurally validate specs and change deltas
The lifecycle
draftreadyactivecompleteverified|rejected← the gate parks insufficient context for human enrichment

Every transition is guarded: ready/active/complete/verified require the change to validate; complete/verified require a finished checklist. A refused transition tells you why.

Workspaces

One job, many repos, any machine.

Real features rarely live in one repository. A portable workspace is a git repo you clone to stand up a whole job to be done: it tracks the manifest (which member repos belong, where to clone them from, which project is the focus) and the job's knowledge wiki — the member repos themselves are materialized beside them, never tracked.

~/jobs/documents-linking/
.shipd-config.jsonmanifest — tracked
.shipd/wiki/the job's LLM wiki — tracked
.shipd/initiatives/goals + per-project context — tracked
documents/member repo — machine-local
tasks/member repo — machine-local
incentives/member repo — machine-local
Clone the workspace, not the repos. /s:workspace clone rebuilds members per machine via the sync ladder: worktree of a local clone → reference-clone → full clone only on a fresh machine.
Knowledge travels with the job. The LLM wiki lives in the workspace repo — wiki writes (/s:teach, queued oracle questions) auto-commit locally and travel with push/pull. The oracle answers from the job wiki first, then your base wiki; job-independent answers get promoted so every future job inherits them.
Drift is reported, never "repaired". The materialization cost is paid once per job, not per task — per-change work in a member repo keeps its own worktree flow.
The supersession gate

Stale plans never build.

Between plan and build, other PRs — especially an autopilot run — may merge work that already implements your plan. Before any execution agent spawns, build syncs the branch with its base and checks every delta against the current capability library.

cleanbuild proceeds — you see nothing
content driftmasters moved for unrelated reasons — build proceeds, reconciling during plan review
supersededa merged PR already did the work — build stops and asks: abandon, or re-scope to what remains

Run it yourself: spec_status.py check-base [change] — findings like id-collision (the plan ADDs a requirement the master already has) are the strongest signal the work is already merged.

What can shipd do

Every capability, one page.

Each entry follows the same shape: the command you run, what happens, and the artifact you get back.

Plan a changecore loop
/s:plan <intent>

Investigates your codebase first, climbs the question ladder for what's left, and compiles intent into reviewable spec artifacts. Stops for your review — it never builds from a guess.

plan.md · delta specs · tasks.md, status: draft
Build a changecore loop
/s:build [change]

Runs the context gate, syncs with the base branch (supersession check), then the orchestrator delegates tasks to execution agents and the validator refutes every scenario before CI + semantic review.

one worktree · one branch · one merged PR
Deep researchintent
/s:research <question>

Turns an open question into a cited research report using the session's web tools — a report that can seed a plan or an epic.

research/<slug>/report.md, every claim cited
Plan from a videointent
/s:video-ingest <file>

Transcribes and diarizes a screen recording entirely on-device, grounds each spoken claim against the frame on screen, and emits a brief that flows straight into planning.

brief.md — timestamp · speaker · frame per claim
Teach the systemknowledge
/s:teach [change Q<n>]

Records a decision into the workspace wiki and the oracle's standing positions — or replays a specific oracle consultation to correct it. Taught once, never asked again.

wiki entry + updated oracle position
Ask the oracleknowledge
automatic during planning

An ask-first agent answers planning questions from your standing positions, with citations. Every consultation is logged in the plan as a referenceable Q<n> ledger entry.

Q<n> ledger entries in plan.md
Run an epicscale
shipd epic <slug>

Groups related changes as members with risk ordering. The autopilot picks the epic up in whatever state it's in and drives every member to a merged PR, gating when needed.

member PRs, parked members reported
Watch deliveryvisibility
shipd board · metrics · list

The live delivery board, throughput metrics, and in-flight change status across the root and all worktrees — JSON-first output for your own tooling.

board · metrics · status, human or JSON
Verify the libraryquality
shipd lint [change]

Structurally validates specs and change deltas — requirement grammar, scenario coverage, delta consistency against the capability library.

findings with file + line, exit code for CI
Stand up a workspacescale
/s:workspace clone <url>

Clones a portable workspace — manifest + job wiki — and materializes its member repos on this machine via the sync ladder: worktree, reference-clone, or full clone.

a ready cross-repo job directory
FAQ

The questions worth asking.

01

Which agents and models does it work with?

shipd ships as a plugin for Claude Code today — its skills are invoked as /s:plan, /s:build, /s:status inside your session. The spec engine underneath is deliberately LLM-free: exact-keyed CRUD over markdown, driven by plain scripts. No model ever reads or writes the library directly.

Roles are model-tiered, not model-locked: the orchestrator plans on the strongest model available, execution agents run one tier down, and the pipeline is config-defined — stages can be skipped, replaced, or extended per workspace, so other runtimes can slot in as the distribution opens up.

02

What does shipd see of my code? What leaves my machine?

The spec library lives in your repository, under your version control — .shipd/ is just markdown you can read, diff, and delete. Agents access your code the same way your coding-agent session already does; shipd adds no second channel.

Heavy inputs stay local by design: video ingest transcribes and diarizes screen recordings entirely on-device — no cloud transcription, no vision APIs — and only the cited brief enters the repo. Audio, frames, and raw transcripts never land in a checkout or a PR.

03

What if the validator is wrong?

The validator can only be wrong in the safe direction. It's adversarial — it tries to refute scenarios against the real, running code. A false refutation sends the change back to the execution agents; nothing is lost but time. And it never merges anything alone: CI must pass and the semantic review must be explicitly dispositioned by design.

When the earlier context gate finds a plan lacking, it doesn't guess — the plan parks as rejected with its findings written into plan.md, and a human enriches it before anything builds. Every guard is also inspectable and overridable: a refused transition tells you why, and --force exists when you know better.