Suede Ship

Suede Ship

The canonical Suede DAG. One prompt in, one shipped change out, with about fifty

agents in between arranged as a graph rather than a chain.

Invoke the workflow bundled at skills/suede-ship/workflows/suede-ship.js. If

you keep a personal copy, ~/.claude/workflows/suede-ship.js works the same way.

Choose this or the fleet first

suede-ship is the surgical instrument and it is the expensive one. Roughly

fifty agents (about fifty-four when deploys is true), research-heavy and

front-loaded, billed to the Claude limit.

If the job is actually high-volume, well-specified, and splits into independent

worker-sized tasks (content batches, test generation, bulk refactors), say so

and offer suede-codex-fleet instead. That runs

on the OpenAI subscription and costs nothing against the Claude limit. Brute

force beats surgery when the work is genuinely parallel and shallow.

Parse the invocation

The argument is free-form. Extract:

• repo — required. An absolute path. Resolve a bare name against ~/code/<name>.

If no repo is named and the cwd is inside a git repo, use that repo's root.

• scope — required. What to change, in the user's own words, kept verbatim

where possible. Do not compress it into a slogan; the planner decomposes it

into lanes and the detail is what makes lanes separable.

• deploys — true if the repo has a vercel.json, a platform project link, or

a known live URL. Check rather than assume.

• liveUrl — the production URL if you know it or can read it from

vercel.json, package.json, or the README. Optional; the release verifier

discovers it otherwise.

• vault — optional absolute path to an external decision store (a synced

notes vault, an ADR archive, a handoff directory). Omitted by default. When

present, the prior-decisions lens reads it as context, never as source truth.

If scope is missing, ask for it. Do not invent a change to a production

repo. This workflow writes code.

State the cost before launching

This is Claude-model fan-out against the weekly limit. Say so in one line before

the call, so the spend is a decision rather than a surprise.

Launch

Workflow({
  scriptPath: "skills/suede-ship/workflows/suede-ship.js",
  args: { repo, scope, deploys, liveUrl, vault }
})

Pass args as a real object. If the harness stringifies it the script recovers,

but an object is correct.

The graph

Nine phases, parallel wherever the edges are not real:

• Scout — fetch origin, dirty files, worktrees, deploy-time landmines. Manifest only.
• Research — multi-modal sweep. Each lens searches a different way and is blind

to the others, because one angle never finds everything. Every claim carries a

file:line, sha, PR, or doc url.

• Gaps — a completeness critic names what went unread, then one bounded fill round.
• Plan — the lane map, with explicit file ownership. High effort by design.
• Build — disjoint lanes, each pipelined straight into its own review.
• Refute — adversarial verifiers, refute-by-default, majority kills the finding.
• Gate — a real barrier: typecheck, build, and tests on the integrated worktree.
• Release — adversarial release verification: config drift, public surface,

irreversibility, live baseline.

• Handoff — the evidence record: changed files, commands run, verification, caveats.

While it runs

Do not predict results or narrate progress you cannot see. The workflow returns a

notification when it completes; /workflows shows live progress.

When it returns

Report faithfully, including the failure shapes:

• halted: true, reason: "blocking hazard at scout" — a real secret in a tracked

file, or a live process holding a worktree this run would touch. Name the hazard.

• halted: true, reason: "lane collision" — the lane map claimed a protected dirty

file, gave one file two owners, or hit a file held by a live sibling worktree.

Report the collisions. The fix is a re-plan, not a retry.

• Completed — lead with shipVerdict and gatePassed, then confirmed findings, then

crossWorktree overlap (files this work will need rebasing against other branches),

then droppedConstraints (what the skeptic rejected) and unread.

Naming what went unread is most of the honesty.

Verdict is advisory

The shipVerdict changes what you report, never what you do. The single exception

is live production exposure the verifier observed independent of this change, such

as a real secret or an unauthenticated 200 that should not exist. That goes to the

user immediately.

Do not claim deployed, verified live, or released. This workflow only reads

production. Those states require a deploy that has not happened.

Iterating

Edit the script and re-invoke with the same scriptPath. Add

resumeFromRunId: "<run id>" to replay unchanged agents from cache. Changing an

agent's prompt or schema re-runs that agent and everything downstream of it.