Architecture
Architecture
One crew, compiled for your harness. The workflow made explicit.
One mental model to keep: Shipmates ships a single canonical crew and command set, and the shipmates CLI compiles it into whatever your harness understands — so you install once and get the same crew on Claude Code, Cursor, or Codex, each getting only the features it supports. The workflow keeps planning, implementation, verification and review explicit, while each harness receives only the features it supports. The rest of this page is those layers in detail; the internals are here if you want them, but you don't need them to use the crew.
The big picture
Three layers, one direction of travel: one canonical crew in, a native payload for your harness out, and a structured workflow with explicit quality gates.
shipmates CLI through seven per-harness adapters into native payloads — each carrying only the features its harness supports.Everything below is just those three boxes in more detail. What matters for you: the crew is written once, so nothing is harness-specific until the CLI compiles it — and what lands in your project is always native to the harness you chose.
One source of truth
Shipmates defines the 12 crew, 13 commands and the tools once, in a harness-neutral form — so every harness gets the same crew.
The crew are twelve specialist subagents; the commands are thirteen workflows like /ship-issue; the tools are model-invoked helpers. All are domain-neutral by rule — no stack, framework or product is named — so the same crew works on a game engine, a web app, or a CLI without configuration.
Because there is a single definition behind every harness, a fix or a new command reaches all seven at once; you never re-learn the crew when you switch harness. (These canonical sources live in the repo as crew/*.md, commands/*.md and toolbox/* — the starting point if you ever want to fork and customize, though that's an advanced path, not something using the crew requires.)
Feature-aware adapters
Each harness gets exactly what it can use — and nothing it can't — so the install is always native, never a lowest-common-denominator port.
The shipmates CLI is a single binary that carries the canonical crew and compiles it through one adapter per harness. Each adapter knows its harness's native file shape and frontmatter dialect, the exact paths it reads (.claude/, .opencode/, .agents/skills/, and the rest), and its least-privilege tool scopes — so you don't configure any of that.
Crucially, an adapter emits only the features that harness actually supports — per-agent model and reasoning effort, subagents versus skills-only. Where a harness lacks a feature, the adapter records the gap instead of inventing a key, so nothing silently breaks. The per-harness feature map is tracked in the repo and checked in CI; the reader-facing version is the harness matrix.
How it stays honest
Every target's output is byte-compared against a committed digest, and CI fails on drift.
Each adapter's payload is deterministic and checked against tests/payload-digests/<name>.sha256; the feature matrix is validated too, so adding a frontmatter key without registering it fails the build. The site you are reading is generated from the rendered Claude Code payload and gated the same way.
Nothing here is described as runtime-tested on a harness Shipmates has not been run on.