From shipwright
The operating method for autonomous build-and-ship work. Load it when you're about to build, code, refactor, fix, review, or ship a web app or service, or when running a self-directed work loop, and you want to work the way the rest of the toolkit expects: the loop to run, which sibling skill to invoke, how they chain, and the disciplines that keep the work honest. Not a router (the harness already picks skills) and not a task tracker — the method an agent runs WHILE doing the work. Triggers with 'shipwright', 'how should I work on this', 'start building', 'work loop', 'ship this', 'autonomous dev loop', 'what's the right way to build this'.
How this skill is triggered — by the user, by Claude, or both
Slash command
/shipwright:shipwright [optional: the task or 'loop'][optional: the task or 'loop']The summary Claude sees in its skill listing — used to decide when to auto-load this skill
The shared operating method for an autonomous agent that builds and ships software. The harness
The shared operating method for an autonomous agent that builds and ships software. The harness already decides which skill fires; shipwright is the layer above that: the loop you run, the skills you invoke and how they chain, and the judgement that keeps it honest. It exists so a fleet of agents across many machines ships the same way, and a new one inherits the whole method on day one instead of a pile of separate tools.
Two ways it's used:
It is not a router (don't re-derive what the harness does by description-matching), not a duplicate of your rules (it references them), and not a checklist that replaces thinking.
One work tick, and the session it lives in:
read the signals → pick the highest-value thing → branch
→ build → verify with proof → ship (staging → prod gates)
→ post the outcome → improve → repeat
To run this as a recurring self-directed loop (not just once), schedule it with the loop skill
(session-local) or schedule skill (cloud cron); each firing re-enters this method. Tighten or ease
the interval per the cadence rule below.
Each row is an installed sibling skill. To use one, invoke it by name (/decisions,
/brainstrust, and so on) so its full method loads, then follow it. The row is a one-line signpost,
never the skill itself — improvising the skill's job from the row instead of loading it is the mistake
this section exists to prevent.
Gate yourself first. You answer most questions by reading the code or taking the obvious default. Invoke a skill only when the task earns it: a panel for a trivial call, or asking a human what you could look up, costs more than it saves.
Match the skill to the task — the chain matters more than any single move:
| To do this… | Invoke | Notes |
|---|---|---|
| get a human's decision | decisions | one clean ask, one tap; often fed by brainstrust |
| show a person a page / get richer-than-a-tap input | share | a purpose-built web page on one link, structured answer back: compare options side by side, approve or edit a draft, mark up a mockup, fill a form. Sibling of decisions — decisions is one tap over chat, share is when the call needs a surface |
| get an outside / other-model read | brainstrust | its output is input, not verdict — verify before acting (the brainstrust skill, not the older dev-tools:brains-trust) |
| prove a change works / review before ship | verify · run · code-review / security-review | the §1 "verify with proof" + "ship through gates" steps — don't hand-roll them |
| prove a bug is fixed (before/after evidence) | fixer | closes what a review or panel opened |
| check comments/docs match the code | honesty | run before you trust a comment you'll act on |
| onboard / demo the app | walkabout | guided tour, ask-the-app, demo videos |
| keep driving the bar over time | perfection | the outer loop that keeps calling the others |
The arc, not the table, is the doctrine. The full version: a brainstrust panel surfaces a concern →
you verify its claims against the real code → a decisions ask (or a share page when the call needs a
visual — two options to tap between, a mockup to mark up) puts it to the human → you build →
fixer proves it's fixed → perfection keeps watch. But most ticks are leaner and need no fancy
moves — e.g. read signals → pick a dependency security advisory → verify the fixed version is real and
the bump isn't breaking → build → verify/run it works (and be honest if a test can't run locally) →
ship the PR → breadcrumb: no human, no panel, the disciplines alone carry the tick. A new agent can't
infer either arc from the separate skill descriptions; that's why it lives here. Don't invoke moves a
tick doesn't need.
These reference your rules; they are not copied here. They are the difference between shipping and shipping well:
A user-facing change adds checks the back-end disciplines don't cover. These are inline — don't reach for a separate design tool; they're the floor:
<button>), labelled inputs,
sufficient contrast, keyboard-reachable. Baseline, not optional polish.A skill auto-loads by its description — but an agent reads the project's CLAUDE.md
(or AGENTS.md) first, and if that brief never mentions the toolkit, a fresh agent may
never reach for it. So the first time you run shipwright in a repo — especially as the loop —
verify the repo is wired:
CLAUDE.md / AGENTS.md reference the shipwright method and the current sibling
set? If it's missing, or has drifted (names a retired skill, or omits one that now
exists), offer to add or update a short Operating-method block. CLAUDE.md is
human-owned — propose the edit, don't make it silently.Running this check on every pickup is what stops the block from rotting: the wiring stays
current because shipwright reconciles it each time, rather than every repo's CLAUDE.md
drifting the moment the toolkit changes. (That self-heal is the whole point — it's what makes
listing the skills safe.)
Make the block directive, not just a pointer. A names-only list ("these skills exist, see
shipwright") fixes discovery — an agent that didn't know the toolkit existed. But the more common
failure is the in-flow miss: an agent that knows the skill exists still improvises past it in
momentum (e.g. dumps a wall of questions at a person instead of invoking decisions). A pointer
doesn't catch that; a trigger → skill mapping in the always-loaded brief has a chance to, because
it fires at the decision point. So the block maps trigger → skill inline, and still defers to this
skill for the chains and depth (single source). The per-pickup wiring-check keeps the trigger list
current, so the inline list self-heals rather than rotting. The block to add:
Operating method — shipwright. Build and ship via the
shipwrightskill (load it for the loop + how the moves chain). When one of these triggers comes up, invoke the named skill instead of improvising its job — invoking loads the skill's full method; the line here is the trigger, not a substitute:
- about to ask a person a decision →
decisions(one clean ask, never a wall of questions)- want a page / richer-than-a-tap answer from a person →
share- want an outside / other-model read →
brainstrust(its output is input, not verdict)- proving a bug is fixed (before/after evidence) →
fixer- checking comments/docs actually match the code →
honesty- onboarding or demoing the app →
walkabout- keeping the quality bar driven over time →
perfection
(Adjust the list to the siblings actually installed — that's what the wiring-check reconciles.)
Keep this doctrine slow-changing. Push fast-moving specifics down into the rules it references, so shipwright stays the method and doesn't rot into a changelog.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub jezweb/shipwright --plugin shipwright