claude-code - 💡(How to fix) Fix [FEATURE] Allow skills to invoke other skills with per-skill model selection [1 comments, 2 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Current limitation: A skill runs on whatever model the user is chatting with. There's no way for a skill to delegate work to another skill, and no way to specify that a particular skill should run on a particular model regardless of the caller's current model.

What I want: Modular skills that can be composed — either as a pipeline (orchestrator) or behind a dispatcher (router) — where each sub-skill declares its own model requirement and is invoked on that model.

Example: A research-and-draft orchestrator skill that does three things:

1. Haiku — parse the user's request, extract entities, classify intent. Cheap, fast, high-volume.
2. Sonnet — run the research loop (search, fetch, synthesize sources into structured notes). Balanced cost/quality for iterative tool use.
3. Opus — take the structured notes and produce the final long-form draft. Expensive, used once, where reasoning quality matters most.

Today I'd have to either run the whole thing on Opus (wasteful) or on Sonnet (my preferred middle ground). I want the orchestrator skill to invoke each sub-skill on its declared model and stitch the results together.

Why this matters:

• Cost control. Most orchestration work is classification, routing, and glue — Haiku-shaped problems. Reserving Opus for the one step that needs it changes the economics of complex skills.
• Composability. Modular skills are only useful if you can combine them. Right now "skill A calls skill B" isn't a primitive.
• Right tool for the job. A router skill picking between specialists should itself be cheap; the specialists it routes to can be expensive where justified.

Proposed Solution

Shape of the feature:

• Skills can declare a preferred/required model in their metadata.
• Skills can invoke other skills (by name or capability), and the invoked skill runs on its declared model, not the caller's.
• Results return to the caller, which continues on its own model.

Note: this is similar to #49363

Alternative Solutions

Manual model swap via stop-and-summarize. If I want a different model for part of the work, I ask the orchestrator to stop at a checkpoint, summarize state to a file, and hand off. I then open a new chat on the target model and share the file to reload context.

Why this doesn't work:

• Breaks pipeline mode. Each handoff is a full context reset. The orchestrator can't drive a multi-stage pipeline end-to-end — I become the glue between stages.
• Context loss. Summarize-to-file is lossy by design. Nuance, intermediate reasoning, and tool-call history don't survive the round trip.
• Manual overhead. Every model switch costs me a file write, a new chat, a re-share, and a re-prime. For a 3-model pipeline (Haiku → Sonnet → Opus), that's two manual handoffs per run.
• No router pattern. A dispatcher skill that picks a specialist based on input can't actually hand execution to that specialist on a different model — it can only tell me to go do it myself.
• Not automatable. The whole point of skills is codifying a workflow. A workflow that requires human-driven chat switching isn't a workflow, it's instructions.

Other workarounds considered:

• Run everything on the highest-tier model. Works but defeats the cost argument — most steps don't need Opus.
• Run everything on the lowest-tier model. Output quality collapses at the stages that actually need reasoning.
• External orchestration (API-level). Feasible but moves the work out of Claude skills entirely, losing the ergonomics and composability that make skills useful in the first place.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

Use case example: Research-and-draft pipeline for freelance articles

I write freelance articles and want a skill that takes a client brief and produces a researched first draft. The work naturally splits into three stages with very different cost/quality profiles.

The skill: article-pipeline — an orchestrator that chains three sub-skills.

Step-by-step

1. I invoke the orchestrator with a client brief.

"Draft an 800-word article on the impact of the EU AI Act on SaaS startups. Target audience: technical founders. Tone: practical, not academic."

2. Stage one — brief-parser runs on Haiku.

Extracts structured data from the brief: topic, word count, audience, tone, angle, deliverable type. Returns a JSON object. This is pattern-matching work — Haiku handles it in under a second for pennies. Running it on Opus would be wasteful.

3. Stage two — research-agent runs on Sonnet.

Takes the parsed brief and runs an iterative research loop: web searches, fetches primary sources (the Act itself, commentary, affected company statements), synthesizes findings into structured notes with citations. This is tool-heavy, multi-turn work where Sonnet's balance of reasoning and speed matters — Haiku would miss nuance in legal text, Opus would burn budget on what is ultimately information gathering.

4. Stage three — draft-writer runs on Opus.

Takes the structured notes and produces the 800-word draft. This is the one step where reasoning quality directly determines output quality: voice, argument structure, transitions, choosing what to cut. Opus earns its cost here. It runs once, on pre-digested input, so the token count is bounded.

5. Orchestrator returns the draft to me along with the research notes (so I can verify claims) and the parsed brief (so I can confirm the skill interpreted me correctly).

What the economics look like

Rough shape per run:

• Brief-parser on Haiku: negligible.
• Research-agent on Sonnet: moderate — several tool calls, mid-size context.
• Draft-writer on Opus: small-to-moderate — one call, pre-digested input.

Versus running the whole pipeline on Opus, which would spend Opus rates on 20+ research tool calls that don't need Opus-level reasoning. Versus running it all on Haiku, where the draft would be unusable.

Why the workaround fails here

I can't stop-and-summarize between stages — the research stage is iterative and stateful, with tool-call history that matters for the draft. Dumping it to a file loses the reasoning trail. And doing two manual handoffs per article (Haiku → Sonnet → Opus) makes the skill worse than just writing the article myself.

Router variant

Same three sub-skills, different wrapper: article-router looks at the brief and picks one specialist. "This is a 200-word news summary" routes to a Haiku-only quick-draft skill. "This is a 2,000-word deep analysis" routes to the full pipeline above. The router itself is Haiku-shaped work — cheap classification — dispatching to specialists that run on their own declared models.

Additional Context

No response