shipyard

Why it exists

The pipeline this one replaces was audited against 110 shipped tickets. 46% of their 1,454 requirements were delivered as specified. Every completion note read as complete.

The failure wasn't effort; it was structure. The agent that built each feature also graded it done. Every behavioural obligation had a prose escape hatch ("or record the path as unverified"), and the escape got used. The only admissible evidence was a file-and-line-number citation, so the cheapest kind of proof always won.

shipyard is the rebuild. The stages are the same shape a human team would use (intake, triage, plan, design, build, verify, remediate); what changed is who gets to say a thing is finished, and what counts as proof.

What's different, in one table

	The predecessors	shipyard
Who grades "done"	The agent that built it	A fresh-context verifier from a different model family
Failure path	None; the last status was "Developer Review"	Needs More Work exists, and the verdict table is the work order
Evidence	file:line for everything	Typed: visual claims need a browser measurement, behavioural claims need an exercised request or a red-to-green test
Design	A phase with no reviewer	A stage with a state matrix, gated by design-review and be-my-witness, findings actioned
Tests	Required at the largest plan tier only	A test strategy per plan: seams named, every flow and menu mapped, criteria falsifiable at the base commit
Ambiguity	Ask the human, or guess	A decision gate: look it up, divergence-test it, get a second model's opinion, then record the assumption with the alternative it beat
Substrates	Two hand-synced twins (markdown + tasks board)	One tracker adapter; the phase text exists once
Implementation	One executor CLI	An ordered lane set (agy, grok, codex) with wire verification and a Claude fail-back

The stages

intake turns a rough idea into briefs, and proposes the companion features your audience would expect as separate, deletable files. triage grounds every claim in the actual codebase and converts ambiguity into recorded assumptions rather than questions; access-control defaults are the named exception, because those are genuinely yours to make. plan writes and commits the build plan plus the test strategy. design mocks every surface and state for iPhone, iPad, Mac and Web, and doesn't hand off until its review gates pass. work builds in an isolated worktree and fills evidence tables as it goes. verify is the stranger: fresh context, re-derives the requirements from the ticket alone, measures the running app, and routes the verdict to a model outside the builder's family. gap-fix is the road back when verification fails.

Note: verify is the only stage that can set Done. That's the point of it.

Install

/plugin marketplace add fledgeling-co/fledgeling-plugins
/plugin install shipyard@fledgeling-plugins

The conductors that drive these stages ship separately: ship-feature for one feature end to end, ship-fleet for a whole backlog, ship-armada for a portfolio.

Does it actually work?

Two kinds of test, both run against snapshots of the predecessor skills on the same fixtures, same model, same prompts.

The report card (structural assertions, graded by an independent agent with quoted evidence): the rebuilt skills passed 37 of 37; the predecessors passed 22 of 37. Every one of the 15 failures was a genuine absence rather than a wording quibble: no named test seams, no state matrix, no verifier family, no failure state, no intake stage.

The blind taste test (anonymised A/B pairs, judged by three model families that never saw which side was which): 17 votes to 4 for the rebuild. One eval lost the first round 1-2; the judges' reasons became two new rules in the triage skill the same day, and the re-judged pair flipped to 2-1 the other way. One judge still dissents, and the dissent is genuinely interesting; it's in EVALS.md with everything else, including what went wrong with the fourth judge seat and which assertions we had to rewrite because they couldn't fail.

The research behind the design decisions is committed too: four deep-research reports (about $9.70 of API spend, every citation machine-checked for fabrication) in docs/deep-research/, and a rule-by-rule traceability file in references/evidence.md that says which numbers are measured and which are policy.

Credit where it's due

shipyard stands on its predecessors in diolog-plugins (feature-spec-pipeline and diolog-tasks-pipeline; their incident-hardened operating rules survive here verbatim). Several concepts are borrowed with thanks from Matt Pocock's skills library (MIT): the fog-of-war test for what can be deferred, the facts-vs-decisions split, seam-agreed testing, and tracer-bullet slices. The acceptance-criteria contract and the physically isolated reviewer come from Vercel Labs' eve-software-factory-template (MIT). The decision gate is the clarify skill's, applied pipeline-wide.

</p>