A single skill does one thing. Real tasks often require many skills. Composition is how Claude combines skills to handle complex requests.
This page covers how composition works and the design patterns that make it reliable.
Claude can invoke multiple skills during a conversation:
User: "Implement feature X"
↓
Claude invokes: brainstorming skill
↓
[design discussion]
↓
Claude invokes: writing-plans skill
↓
[plan written]
↓
Claude invokes: test-driven-development skill
↓
[implementation]
↓
Claude invokes: requesting-code-review skill
↓
[review]
Each skill handles its phase. Together they produce the outcome.
Each skill is loaded into context when invoked. Earlier skill outputs inform later skills implicitly — they're in the conversation.
Patterns:
The "state" is the conversation history. No special passing mechanism needed.
Skill A → Skill B → Skill C. Each completes before the next.
The most common pattern. Each step depends on the previous.
Skill A determines the path:
Skill A: detect language
├── If Python: Skill B (Python style)
├── If Java: Skill C (Java style)
└── If TypeScript: Skill D (TS style)
The first skill's output drives which skill comes next.
Skills don't usually run in parallel within Claude's flow. Workflows that branch then converge are usually serialized: do A, do B (which uses A's result), do C.
Spawning subagents is one way to parallelize. See multi-agent patterns.
A skill may invoke itself for sub-problems. "Decompose into sub-tasks; solve each; combine."
Common in planning skills.
If a skill does multiple things, it composes poorly. Other skills can't cleanly invoke a piece of it.
Smaller, focused skills compose better than monolithic ones.
What does the skill expect from prior context? What does it produce?
Even informally — "this skill assumes a plan has been written" — helps composition.
Skill A wrote tests; Skill B shouldn't write the same tests. Each builds on prior; doesn't redo.
Re-invoking a skill should be safe. If composing involves backtracking ("redo this step"), idempotency matters.
Some skills determine how to approach a task (brainstorming, planning, debugging). Implementation skills come after.
The system prompt guides this: brainstorming/planning before implementation.
After significant work, verification:
Catches problems before declaring success.
Some skills explicitly reference others:
After completing the implementation, invoke the requesting-code-review skill.
Builds workflows from individual skills.
Some skills' job is breaking a problem into smaller pieces, then invoking other skills for each piece.
Common in plan execution.
Two skills may disagree. "Always TDD" vs. "no tests for this kind of code" — which wins?
Resolution: explicit ordering or clearer scope per skill.
Claude knows about installed skills. If a skill that would help isn't installed, composition fails.
User-facing: skills should be discoverable and well-described.
Skill B assumes Skill A ran first. If invoked alone, B may produce surprises.
Mitigation: B's instructions check for needed state.
Many skills in sequence; long contexts. Skills that work alone may not work in long compositions.
Mitigation: skills should be context-light when possible.
Building a feature with the superpowers system:
User: "Add a search feature to the wiki"
Step 1: brainstorming skill
- Clarify scope, identify constraints
- User confirms direction
Step 2: writing-plans skill
- Detailed implementation plan
- User reviews
Step 3: writing-skills skill (if creating new abstractions)
- Optional; creates reusable skill if pattern emerges
Step 4: test-driven-development skill
- Write failing tests
- Implement to pass
Step 5: requesting-code-review skill
- Review against requirements
- Address feedback
Step 6: finishing-a-development-branch skill
- Decide merge strategy
- Complete the work
Six skills compose for one feature. Each handles its piece.