Claude Code Skills: 6 Stacks That Turn One Tool Into a Fleet

The first time someone asks what a Claude Code skill actually does, the honest answer undersells it. "It runs your test suite and tells you what's undertested." "It checks your build, lint, and tests before you push." Said one at a time, Claude Code skills sound like linters with better manners.

That framing is wrong, and it's wrong in a specific, useful way: it evaluates each skill in isolation instead of as a component in a pipeline. I run 325 agents in production, and none of the load-bearing workflows in that fleet are a single skill firing once. They're stacks — two, three, four skills chained in a fixed order, each one gating the next, each one cheap enough to run every time. The individual skill is the unit. The stack is the system.

This post walks through six of those stacks, built entirely from the 7 free skills anyone can run with no signup: quality-check, verify, scaffold-tests, build-fix, debug-investigate, pressure-test, and learn. None of this requires a paid tier. It requires understanding that a skill is infrastructure, not a trick.

---

The One-Tool Illusion

Here's the failure mode I see most often when engineers first pick up Claude Code skills: they run /quality-check once, get a coverage report, fix the top finding, and move on. Useful, but it's a snapshot. It answers "what's risky right now" and stops there.

The fleet doesn't run skills as snapshots. It runs them as gates in a sequence, where the output of one skill is the input condition for the next. build-fix doesn't get invoked because someone remembered to check the build — it gets invoked because scaffold-tests just added a test file and the CI config it wrote doesn't compile yet, and the next skill in the chain refuses to proceed until it does. That's the difference between a tool and a fleet component: a tool waits to be picked up, a fleet component is wired into what happens next.

Why Claude Code Skills Compose Into Systems

Composition works here for the same reason AI Agent Design Patterns hold up in production: each skill has a narrow, well-defined job and a predictable output shape, so the next skill in the chain can consume it without guessing. debug-investigate doesn't just print logs — it produces a persistent eliminated-hypotheses trail that build-fix can read so it doesn't re-propose a fix that already failed. learn doesn't just summarize a session — it writes categorized entries (pattern, anti-pattern, convention) that feed the next quality-check run's risk ranking. The skills were built to hand off state, not just print output to a terminal.

That's the part that makes six stacks possible out of seven skills: the composability isn't accidental, it's the design. I go deeper on this exact mechanism — narrow tools, explicit handoffs, guardrails between steps — in AI Agents in Production: The Operator's Handbook, which is the pillar piece this whole series builds from.

Six Stacks From Seven Skills

1. The Ship Gate

scaffold-tests → build-fix → verify → quality-check

This is the stack that runs before anything merges. scaffold-tests detects the stack (Python, Node, Go, whatever), writes real test files with actual assertions, and wires a CI workflow. build-fix immediately follows to catch anything that new scaffolding broke — missing imports, a lint config that doesn't match the new test runner. verify runs the full build → lint → test → secrets-scan loop and produces a hard PASS/FAIL. quality-check closes the loop by ranking what's still undertested, so the next PR knows where to start.

Four skills, one command each, and the sequence encodes an entire "definition of done" without anyone having to remember what done means that week. In practice it reads like this — no orchestration script, just one skill handing off to the next:

/scaffold-tests
> detected: node, vitest not configured — installing, writing CI workflow
> 6 test files created with real assertions, coverage baseline set

/build-fix
> re-running build after scaffold changes... 1 missing import found and fixed
> build clean

/verify
> build: PASS · lint: PASS · tests: PASS · secrets-scan: PASS

/quality-check
> coverage: 71% · top untested path: webhook signature validation

Nobody had to remember to run four separate checks in the right order. The order is the point — quality-check at the end is only trustworthy because build-fix and verify already ran first.

2. The Pre-PR Gate

pressure-test → debug-investigate → verify

This stack runs earlier — before code exists, or right after a first draft. pressure-test runs the premortem: what breaks, what's the blind spot, what's the ranked risk. Anything that surfaces a real failure mode gets handed to debug-investigate, which works it with the scientific method and keeps a persistent eliminated-hypotheses log so the same dead end doesn't get re-walked next session. verify runs last as the objective check — not "does this feel solid" but "does the build, lint, and test suite actually pass."

The order matters. Running verify first tells you the code compiles. Running pressure-test first tells you whether the code should exist in its current form at all.

3. The Learning Loop

learn → quality-check

The smallest stack here, and the one that compounds the most over time. learn extracts reusable patterns from a session — tagged as pattern, anti-pattern, or convention — into project memory. quality-check then runs against that same codebase with the benefit of what was just captured: an anti-pattern flagged this week shows up as a risk signal in next week's coverage scan. Two skills, but the second run of quality-check is measurably sharper than the first, because learn fed it context it didn't have before.

This is the same mechanism I cover in AI Agent Memory: Agentic RAG That Survives Restarts — a system that doesn't retain anything between runs re-derives the same conclusions at the same cost, every time. A system that writes memory and reads it back gets cheaper and more accurate on every pass.

4. The Incident Response Stack

debug-investigate → build-fix → verify

Production broke, and the sequence changes because the stakes change. debug-investigate establishes root cause first — no guessing, no shotgun-fixing — before anything gets touched. Only once a hypothesis is confirmed does build-fix apply a minimal, targeted change, one error at a time, re-running the build after each fix. verify is the final gate before anyone calls it resolved: the incident isn't closed because the fix looks right, it's closed because the full suite passes clean.

This is the same discipline behind Three PRs. One Morning. — three independent fixes, each one root-caused before it was touched, each one verified before it was called done. Speed came from the sequence being disciplined, not from skipping steps.

5. The Cold-Start Stack

scaffold-tests → quality-check

For a repo that has no test infrastructure at all — a fresh clone, an inherited legacy service, a prototype that's about to see real traffic — this two-skill stack is the fastest path from zero to a defensible baseline. scaffold-tests gets a framework installed and a CI workflow committed in one pass. quality-check immediately runs against that new baseline and hands back a top-5 riskiest-path list, so the first real engineering hours go toward the highest-leverage tests instead of whatever file happens to be open.

6. The Assumption Stack

pressure-test → learn

Not every stack is about code. This one runs before a decision — an architecture choice, a go/no-go on a feature, a "this system is good enough" claim someone wants pressure-tested. pressure-test runs the adversarial pass: premortem, blind spots, ranked risk. Whatever holds up — or whatever gets killed — gets written down by learn, so the reasoning behind the decision survives past the meeting it was made in. Six months later, when someone asks "why did we build it this way," the answer isn't a Slack thread nobody can find. It's a lesson entry with a timestamp.

What This Doesn't Replace

None of these six stacks require anything beyond the 7 free skills. What they don't give you: multi-agent teams with separate file territories and peer messaging, a critic loop that automatically re-plans on a failed review, or org-wide sweeps across 110+ repos in parallel. That's what the paid tiers add — quality-team-pro, feature-team, full swarm orchestration — but the free stacks above are not a stripped-down preview of those. They're the same operational discipline at single-repo scale, and for most engineers, that's the whole job most days.

The pattern generalizes past this one tool, too — the same "narrow skill, explicit handoff, gate before proceeding" shape shows up in how tesseractintelligence.io structures agent orchestration for trading systems, where a signal skill, a risk-validation skill, and an execution skill run in a fixed sequence for the same reason: composability beats a single skill trying to do everything.

Start With What's Free

You don't need a fleet to start stacking. You need two skills and a reason to run them in order. Start with verify before your next push, add quality-check the week after, and once those two are habit, layer in scaffold-tests, build-fix, debug-investigate, pressure-test, and learn as the situations that need them come up.

All 7 are free, no signup, full SKILL.md included: jeremyknox.ai/skills-library.