Skill Chaining: Loading Multiple Skills in One Task

By Yanni Papoutsis | 6 min read | 2026-07-10

Claude can load more than one skill for a single task whenever more than one installed skill's description matches, and skill chaining is simply the practice of designing that overlap on purpose instead of leaving it to chance. Done well, one broad "hub" skill routes to a small set of narrower "companion" skills based on the task type; done badly, unrelated skills co-trigger at random and quietly eat your context budget.

This is the third post in the skills-authoring series, following writing a skill from scratch and getting triggers right. Chaining sits on top of both: you cannot design a reliable chain until each individual skill triggers predictably on its own.

TL;DR: Chaining happens whenever a task matches more than one skill's description, which Claude allows by design so that, for example, a session-bootstrap skill and a file-naming skill can both be active for one task. There are two patterns worth telling apart: parallel co-trigger, where independent skills happen to both match, and hub-and-companion, where one deliberately broad skill reads a routing table and tells Claude which narrower skills to load for this task type. The hub pattern is more maintainable at scale because the routing logic lives in one place instead of being smeared across every skill's description. The main risk with any chain is context cost: each loaded skill body counts against your budget, so the routing table should load companions only when the task type actually needs them, and companion bodies should stay short with detail pushed into their own references/ files. Test the full chain end to end, not just whether the hub skill loads.

What does it mean for Claude to chain skills?

Chaining just means two or more skill bodies are in context for the same task. This is a normal, supported outcome of description matching, not an edge case to prevent. A task like "write and publish a blog post" plausibly needs an SEO checklist, a website-building checklist, and a claim-verification skill all at once, each contributing a different slice of the work.

The design question is not "should skills ever combine," it is "which combinations are intentional, and which are accidental."

Two chaining patterns

Pattern 1: Parallel co-trigger

Two independently written skills both have descriptions broad enough to match one task, and Claude loads both without either skill knowing the other exists. This works fine for a small number of skills, but it scales badly: as you add skills, the number of possible pairwise collisions grows fast, and nobody owns the combination.

Pattern 2: Hub-and-companion

One skill is written to be the entry point. It has a deliberately broad description so it loads on almost anything, and its body contains (or points to) a routing table mapping task types to companion skills. The Cowork navigator skill is a working example of this: it loads on the first message of a session, then reads a companions table and loads file-naming, token-budget, or verification skills depending on what the task actually is.

# references/companions.md

| Task type | Load these skills |
| --- | --- |
| Any web/HTML/CSS/JS work | website-building-checklist, seo-ai-checklist |
| Long or file-heavy session | token-budget |
| Factual or research content | anti-hallucination |
| File save or export | file-organization |

The hub owns the decision. Companion skills stay simple and do not need to know about each other.

How do you build a hub-and-companion chain step by step?

Step 1: Build the hub skill with a broad description

name: content-pipeline-hub
description: Coordinates content creation tasks. Load on any request
  to write, publish, or update a web page, blog post, or landing
  page. Routes to companion skills based on task type.

Step 2: Write a companions routing table

Keep the table as data, either inline in the hub's body for a short list, or in a references/companions.md file if it is long. Each row should be a task-type-to-skill mapping, not a vague heuristic.

Step 3: Keep companion loading conditional, not automatic

The hub's instructions should tell Claude to load a companion only when the row actually matches, not to load every companion on every run:

1. Read the task and identify its type from the table above.
2. Load only the skills listed for that task type.
3. If no row matches, proceed without loading additional skills.

This single rule is what keeps a hub-and-companion system cheap as you add more companions over time.

Step 4: Test the full chain, not just the hub

Confirm the hub loads, confirm it loads the correct companions for two or three different task types, and confirm it loads no companions for a task type that should not match any row. That third case is the one people forget to test.

How do you keep chained skills from blowing the context budget?

Every loaded skill body is a line-item cost. Three habits keep a chain affordable, covered in more depth in the token budget skill guide:

• Keep each companion's SKILL.md body short; push long material into that skill's own references/ folder.
• Route conditionally, so a five-companion system rarely loads all five at once.
• Prefer one well-designed hub over five overlapping broad skills, since the hub centralises the routing decision instead of repeating trigger logic in every skill's description.

Ordering: which skill loads first?

When a hub pattern is in use, the hub should load first and finish its routing step before companions load, so its decisions are based on the task alone, not on partial output from a companion. For parallel co-trigger skills with no hub, ordering is less controllable, which is itself an argument for moving to a hub pattern once you have more than two or three skills that regularly combine.

Common chaining mistakes

Frequently asked questions

Is chaining the same as one skill calling another?

Not exactly. Skills do not call each other directly the way functions do. Chaining means multiple skill bodies are simultaneously relevant and loaded for one task; a hub skill creates the appearance of delegation by instructing Claude to load specific companions, but the mechanism is still description-based loading, not a function call.

How many skills can reasonably chain on one task?

There is no fixed limit, but each additional loaded skill adds context cost and complexity. Two to four is common and manageable. Beyond that, a hub-and-companion structure with conditional routing keeps things from growing unpredictably.

What happens if two companion skills give conflicting instructions?

This is a design bug, not a runtime feature. When you notice it, add boundary language to each skill's description or body clarifying which one applies in the overlapping case, the same fix used for trigger collisions in the skill triggers guide.

About the author

Yanni Papoutsis builds AI products, automation pipelines, and technical documentation with Claude, and publishes free tooling and guides at yanni.uk.

Next step: Learn how to pull live information into a skill in the web search inside a skill guide, or explore 1,000+ AI tools at yanni.uk/ai-tools.

Sources

• Claude documentation (agent skills): https://docs.claude.com
• Anthropic (agent and context design): https://www.anthropic.com