Description
When using the Skill tool to invoke forked skills, Edit/Write tools become unavailable at the third level of nesting. The nested skill can only use Bash for file modifications.
Environment
- Claude Code version: 2.1.1
- Using custom skills via
.claude/skills/ directory
- Skills invoke other skills using the
Skill tool
Reproduction Steps
- Create a parent skill (e.g.,
orchestrator) that invokes a coordinator skill via the Skill tool
- Create a coordinator skill (e.g.,
parallelizer) that invokes worker skills via the Skill tool
- Create a worker skill (e.g.,
implementer) that needs to modify files using Edit/Write
- Invoke the parent skill from the main conversation
Expected: Worker skill can use Edit/Write tools to modify files
Actual: Worker skill only has access to Bash, must use sed/echo for file modifications
Minimal Example
.claude/skills/
├── orchestrator/
│ └── orchestrator.md # Invokes parallelizer via Skill tool
├── parallelizer/
│ └── parallelizer.md # Invokes implementer via Skill tool
└── implementer/
└── implementer.md # Attempts to use Edit/Write tools
orchestrator.md:
# Orchestrator
Coordinates work by invoking the parallelizer skill.
Use: Skill tool with skill="parallelizer"
parallelizer.md:
# Parallelizer
Distributes tasks by invoking implementer skills.
Use: Skill tool with skill="implementer" for each task
implementer.md:
# Implementer
Makes code changes using Edit/Write tools.
When invoked: main → orchestrator → parallelizer → implementer
The implementer skill cannot access Edit/Write tools.
Fork Depth Behavior
Main conversation → implementer
✅ Edit/Write available (1 level)
Main conversation → orchestrator → implementer (forked)
✅ Edit/Write available (2 levels)
Main conversation → orchestrator → parallelizer (forked) → implementer (forked)
❌ Only Bash available (3 levels)
Workaround
Flattening the hierarchy to 2 levels restores Edit/Write access. For example, having the orchestrator invoke implementer directly (skipping the parallelizer) works correctly, but loses the ability to coordinate parallel execution.
Additional Observation: Sequential Execution in Forked Skills
Forked skills can only invoke other skills sequentially, not in parallel. Even when a forked skill attempts to invoke multiple child skills concurrently (e.g., multiple Skill tool calls in one message), they execute one at a time. This compounds the nesting limitation—the "parallelizer" pattern not only loses Edit/Write at level 3, but also can't actually parallelize, significantly slowing down multi-level skill workflows.
Questions
- Is this limitation intentional/by design?
- If intentional, what is the rationale? (security, context management, tool permission inheritance?)
- Are there plans to support Edit/Write at deeper nesting levels?
- Is there a recommended pattern for orchestrating multi-skill workflows that need file modifications at 3+ levels?
- Is parallel skill invocation from within a forked skill something that could be supported?
Impact
This limitation prevents common orchestration patterns:
- Orchestrator → Parallelizer → Worker
The parallelizer pattern is intended to run multiple workers in parallel, but:
- Loses Edit/Write capability at the third level
- Cannot actually parallelize child skill invocations
Combined, these limitations make multi-level skill orchestration both slower and less capable than direct execution.
Current workaround of using Bash for edits loses the benefits of the Edit tool (atomic changes, proper conflict detection, cleaner diffs).
Any guidance or clarification on the intended behavior and recommended patterns for this use case would be appreciated.
Description
When using the Skill tool to invoke forked skills, Edit/Write tools become unavailable at the third level of nesting. The nested skill can only use
Bashfor file modifications.Environment
.claude/skills/directorySkilltoolReproduction Steps
orchestrator) that invokes a coordinator skill via theSkilltoolparallelizer) that invokes worker skills via theSkilltoolimplementer) that needs to modify files usingEdit/WriteExpected: Worker skill can use
Edit/Writetools to modify filesActual: Worker skill only has access to
Bash, must usesed/echofor file modificationsMinimal Example
orchestrator.md:
# Orchestrator Coordinates work by invoking the parallelizer skill. Use: Skill tool with skill="parallelizer"parallelizer.md:
# Parallelizer Distributes tasks by invoking implementer skills. Use: Skill tool with skill="implementer" for each taskimplementer.md:
# Implementer Makes code changes using Edit/Write tools.When invoked:
main → orchestrator → parallelizer → implementerThe implementer skill cannot access Edit/Write tools.
Fork Depth Behavior
Workaround
Flattening the hierarchy to 2 levels restores Edit/Write access. For example, having the orchestrator invoke implementer directly (skipping the parallelizer) works correctly, but loses the ability to coordinate parallel execution.
Additional Observation: Sequential Execution in Forked Skills
Forked skills can only invoke other skills sequentially, not in parallel. Even when a forked skill attempts to invoke multiple child skills concurrently (e.g., multiple Skill tool calls in one message), they execute one at a time. This compounds the nesting limitation—the "parallelizer" pattern not only loses Edit/Write at level 3, but also can't actually parallelize, significantly slowing down multi-level skill workflows.
Questions
Impact
This limitation prevents common orchestration patterns:
The parallelizer pattern is intended to run multiple workers in parallel, but:
Combined, these limitations make multi-level skill orchestration both slower and less capable than direct execution.
Current workaround of using Bash for edits loses the benefits of the Edit tool (atomic changes, proper conflict detection, cleaner diffs).
Any guidance or clarification on the intended behavior and recommended patterns for this use case would be appreciated.