Composing skills into pipelines
Track 2 ended with a rule: one skill, one job. This is where that rule pays off. The real power of skills is not any single one — it is composing several focused skills into a process that would be unwieldy as a monolith.
Why single-purpose composes and monoliths do not
Take a process with thirty steps — say, producing a search-optimised article: research, keyword work, outline, draft, internal-linking, a duplication check. You could try to write one enormous skill that does all of it. It would be hard to validate (when the output is wrong, which of the thirty steps failed?), hard to reuse (it only fits this exact process), and heavy in context the whole time it runs.
Break it into a handful of focused skills instead — one for keyword research, one for the outline, one for the draft, one for the duplication check — and each becomes verifiable on its own, reusable in other processes, and lean. That is the whole argument for composition: single-purpose skills are easier to validate, reuse, and fix, and they stay light in context where a monolith crowds everything out.
How the handoff actually works
Be precise about the mental model, because it is easy to over-imagine. There is no separate pipeline engine running your skills for you. Composition is a sequence you design: one skill produces output, the next skill consumes it. Claude carries that handoff within the work — finishing one skill's job and moving to the next — or you invoke each in turn.
That distinction matters for how you build. You are not configuring an orchestration system; you are designing skills whose outputs and inputs fit together cleanly. A keyword skill that emits a tidy list is easy for the next skill to pick up. One that emits a wall of prose is not. Design each skill's output with the next skill's input in mind.
The work loop, encoded
If you have worked through the developer track, you will recognise the shape: read, plan, build, review, commit. A well-composed set of skills encodes that loop. A planning skill produces the change you are about to make; a build skill works from that plan; a review skill checks the result against its own rules before anything is committed. The skills are not a replacement for the loop — they are the loop, made repeatable.
When to split and when to combine
The signal to split is one of two things: the work has several distinct stages, each with its own judgment point — or a single skill's body has grown long enough that keeping it lean is a fight. Both say the same thing: this wants to be more than one skill.
The signal to keep it combined is that the steps are genuinely one judgment — they share context, they happen together, splitting them would just create handoffs with nothing in between. Do not split for its own sake. Split where there are real seams.
A good rule from production: each skill should be something you can describe in one sentence and validate on its own. If you cannot, it is doing too much.
What comes next
Composed skills become far more powerful once they can reach your actual tools and data. The next part covers how skills work with MCP and hooks — connecting a skill to your systems, and using deterministic enforcement around it.
Next in this series: Part 2 — Skills, MCP, and hooks