if nested skill is allowed

[jujiale]

hello, I have some questions about the use of skills

There is a strange usage as follows:
`

A-SKILL
--SKILL.md
--B-SKILL
--SKILL.md
--scripts
--C-SKILL
--SKILL.md
--scripts

`

the A-SKILL is a orchestration skill， B-SKILL and C-SKILL execute the tasks, and A-SKILL orchestrates the information.

I want to know if this usage is allowed, and if this usage contains potential risks， because I find someone use this way,
I wonder whether this usage is standard.

thanks!

[steinybot]

I use this orchestration pattern all the time, especially with Claude Code and context: fork, so that the nested skills have their own isolated context and don't pollute the orchestrator. It is annoying to have to define these all as top level skills where the nested skills make no sense to run on their own and just pollute the command space.

[jonathanhefner]

The spec doesn't say anything about nested skills in particular, but skills may include arbitrary files. For example, you could have:

skill-creator/
├── SKILL.md
└── templates/
    └── SKILL.md

In that case, I would expect clients to not treat templates as its own skill.

[mehvetero]

Been using this exact pattern in practice — a parent skill that delegates to child skills under it.

The structure I ended up with is slightly different from your example though. Instead of nesting B-SKILL and C-SKILL as full skills with their own SKILL.md, I keep the orchestrator as the only SKILL.md and put the sub-tasks as plain scripts or reference docs under it:

my-skill/
├── SKILL.md          (orchestrator — the only entry point)
├── scripts/
│   ├── task-b.mjs
│   └── task-c.mjs
└── references/
    └── shared-patterns.md

The orchestrator SKILL.md tells the agent when to call which script. No nested SKILL.md means no ambiguity about what the client should treat as a skill vs what is internal plumbing.

When I did try the nested SKILL.md approach, the main annoyance was exactly what @steinybot mentioned — the inner skills showed up in the command list even though they made no sense standalone. Moving them to plain scripts solved that without losing the separation.

One thing to watch: if B and C need to share state (intermediate results, a config value), that shared state has to live somewhere the parent can pass it. I use a shared reference file that the orchestrator reads and passes as context to each sub-task. Trying to have B and C read each other directly gets messy fast.