The complete guide
chris-code turns Claude Code from a free-form chat assistant into a spec-driven engineering workflow: settle intent, design before code, dispatch focused agents, and gate drift before it reaches main. It ships 25 skills and a 13-agent layer — and where that breadth is spent tells you what it values.
What it is
It routes every non-trivial change through a fixed pipeline, so the first thing that compiles never becomes the design by default.
A free-form assistant fails three ways on work with a real design space:
chris-code closes all three with a pipeline built from skills (auto-firing instruction modules) and agents (role-scoped subagents, each in its own context). You describe the work; the machinery decides what runs.
The core idea
Settle what and why before how — and write it into durable artifacts a fresh agent can execute without re-deriving your intent.
Why the artifacts, and not just a prompt?
Hand an agent only what and where and it will optimize the diff and ship the wrong thing correctly. So intent is written first, elaborated into contracts, then a thin plan, then code — and the final gate checks the running system back against the original ask. Each artifact is what makes the next handoff lossless.
The intent ledger
Up to seven acceptance statements, in your words, frozen at brainstorm — you approve them, you don't write them. It lives outside the spec on purpose: at verify, a spec-blind reviewer checks the running system against this ledger, making it the only gate that can catch a spec that drifted from what you actually asked for.
The spec keeps behavior, interfaces, and invariants. The plan keeps what and where. Neither pastes code the agent would just rewrite.
If a line would change when you reimplement in another language, it's choreography — it belongs in the plan, not the spec. Code belongs in neither.
A fresh subagent rebuilds its understanding only from what it can read — the brief, the spec, the repo. So the rule: dispatch when the context is recoverable from artifacts; stay in-session when the why lives only in the conversation. The brief always carries the why; everything else it references.
Two kinds of work
The pipeline forks on one question — is what to build already settled? — and sends determined work through a dedicated engine instead of a full design cycle.
answer: no
“What should this be?” is still live — a new feature, a component, a behavior change.
→ brainstorming settles the design, then rejoins the pipeline
answer: yes
Behavior is settled — a refactor, a migration, an API alignment, an already-specced feature. Only which implementation fits is open. Determined ≠ trivial.
→ the coherent-change engine
The engine's premise, and the thing newcomers get wrong: a change can work and still be wrong.
The defended choice — produced every time
the two or three facts from research that change the problem — what's in scope, where the real boundary sits.
concrete and minimal: what changes, what's deleted, what's deliberately left untouched.
a table over all affected cases, plus a required “cases I might be missing, and how I'd find them” line — proving coverage, not asserting it.
reuse, idiom-fit, whether it mirrors an existing strategy, smallest correct blast radius.
a real rebuttal of every rejected candidate — not a one-liner.
The assurance model
A green pipeline means “nothing these lenses caught,” not “nothing is wrong” — the confidence comes from independent checks, not the number of passes.
full suite, zero failures.
project linter, zero warnings.
senior *-design-reviewer agents → PASS / CONCERNS.
every spec item traced to code and a test.
a spec-blind reviewer compares shipped behavior to the frozen ledger.
mutation-tester mutates changed lines in an isolated worktree; gates any test that runs the code but detects no change.
Most gates are LLM judgments sharing a model, distribution, and framing — so they miss the same things together. Stacking them raises recall, never certainty. Only a few axes are genuinely independent, and those are the ones that count:
Conformance asks “does the code match the spec?” — which is not correctness. A build can conform perfectly to a spec that drifted from your ask. Step 5 is the only gate that never reads the spec, which is exactly why it catches that drift.
The 25 skills
The first three groups are the pipeline's spine; the rest cover the change engine, testing, completion, review, campaigns, and meta. Colour marks each skill's nature.
Settle what and why before any how.
Turn a plan into code — dispatched or inline, always isolated.
The universal application point for any determined change.
Test-first, and lock every fix against regression.
The hard gate before "done," then integration.
On-demand senior review, plus how to give and take it.
Repeatable, parallel bug-finding sweeps across a codebase.
How the plugin finds its own skills, and ships itself.
The 14 agents · where the weight goes
Fourteen dedicated agents auto-dispatch by file type. Three are coders; the other eleven test, review, or verify. The plugin spends its agent budget on assurance, not authorship.
A free-form assistant is all author and no auditor. chris-code inverts that: writing the code is the small part; proving it correct is the large one.
It shows up in skills too — of 25, 13 are testing, review, or debugging and 9 are building.
3 coders · 3 quality reviewers · 2 commit-lite gates · 2 design reviewers · 2 conformance · 1 test-writer · 1 mutation gate
One writes the change per task; the rest verify it.
Post-spec review of principle adherence and bugs.
Fast pre-commit idiom + lint: clean / block / escalate.
Senior read-only cohesion / API review at the final gate.
Code↔spec per task; spec-blind behavior↔intent at completion.
Adversarial edge-case test writer, one per subsystem. Never fixes.
Mutation testing in an isolated worktree; gates trivial tests at the final gate, advisory on-demand.
The dispatch difference · most easily missed
superpowers hands work to a generic subagent. chris-code hands it to an agent whose system prompt already knows what good looks like.
superpowers
chris-code
Coming from superpowers?
It forked from obra/superpowers at v5.1.0 and kept the entire pipeline — this is the 20% that changed, and why.
| Inventory | superpowers | chris-code |
|---|---|---|
| Skills | 14 | 25 |
| Agents | 0 | 13 |
| Commands | 0 | 0 |
| Hooks | 1 | 0 |
Every superpowers skill carries over — one renamed (using-superpowers → using-chris-code), one split (writing-plans → lean-plan + lean-spec). chris-code is a true superset: 11 new skills and the entire agent layer on top.
Six thematic shifts
Where muscle memory will mislead you — before → after
| Skill you know | in superpowers | in chris-code |
|---|---|---|
| writing-plans | Exhaustive, full code in every step. | Split: plan slimmed to lean-plan, spec promoted to lean-spec. Spec = contracts; plan = what/where, no inline code. |
| subagent-driven-development | Two-stage review; parallel implementers discouraged. | Three gates per task (spec → quality → commit-lite), scope-based agent selection, deliberate staged parallelism by file footprint. |
| verification-before-completion | Single-command gate: “what proves this? run it.” | Six-step pipeline: Tests → Lints → Design review → Requirements → spec-blind intent re-check → mutation re-check. |
| requesting-code-review | The primary, mandatory review path. | Demoted to ad-hoc — routine review now lives in the automated agent gates. |
If you relied on these, they carry over essentially unchanged (renames aside):
There's also a quieter shift in voice: chris-code strips superpowers' persuasion scaffolding — “Red Flags — STOP” lists, rationalization tables, real-world-impact blocks — for terse, mechanical instructions. Same rules, less rhetoric.
Getting started
chris-code is distributed through a personal Claude Code marketplace. Add it to ~/.claude/settings.json:
"extraKnownMarketplaces": { "chris-code": { "source": { "source": "github", "repo": "chris-santiago/claude-plugins" } } }, "enabledPlugins": { "chris-code@chris-code": true }
Claude Code fetches and caches the plugin automatically. The repo also ships ml-lab and ml-journal — enable those separately if you want them.
Then take one change through the whole pipeline:
/brainstorming. It won't code until a design exists and you've approved it — and it freezes your intent ledger.lean-spec writes contracts; lean-plan writes the thin what/where handoff.