Claude Code: Choosing Between context:fork and the skills Field for Sub-Agents

Introduction

If you search for how to execute skills with sub-agents in Claude Code, the official documentation lists two approaches.

1. context:fork in a skill
2. Sub-agents with a skills field

"Which one should I use? What is the difference?"
You might be asking yourself this.

Even after reading the official documentation, the differences are honestly not very clear. In this article, I will share my understanding of the differences between the two and the criteria for choosing which one to use.

Explanation from the Official Documentation

In the section "Running skills in a sub-agent" on the Skills page, the two approaches are compared as follows:

Approach	System Prompt	Task	Additional Loading
Skill's context:fork	From Agent type (Explore, Plan, etc.)	SKILL.md content	CLAUDE.md
Sub-agent with skills field	Sub-agent's own markdown body	Claude's delegation message	Preloaded skills + CLAUDE.md

Although they are similar, there do seem to be differences. However, I still don't quite get it.
Let's take a closer look at how behavior might change from each perspective.

Comparison from Each Perspective

System Prompt

First, regarding system prompts, simply put, they are instructions that provide the AI with basic behavior and knowledge. They define "what you can do, what you should do, and what you should do," or the opposite.

For example, the built-in Explore agent in Claude Code should have a system prompt such as "Investigate. Do not edit. Report the summary."

When using a built-in sub-agent with a skill's context:fork, you don't need to write these basic behaviors yourself. Conversely, with a sub-agent with a skills field, you need to write those behaviors down.

While it is certainly more flexible, building a sub-agent with a level of perfection comparable to Claude Code's built-ins is not easy, so the ability to use them is a clear advantage of context:fork.

As for custom sub-agents, there seems to be no difference between the two.

Task

This is the most significant difference.

Characteristic	Skill's context:fork	Sub-agent with skills field
Task Definition	Fixed in SKILL.md (Static)	Claude's delegation message (Dynamic)
Predictability	High	Low
Flexibility	Low	High
Debugging	Easy (known input)	Difficult (delegation content may vary)

With context:fork, the content of SKILL.md becomes the task itself.

---
context: fork
agent: Explore
---

Investigate $ARGUMENTS and report the structure.

On the other hand, with a sub-agent with a skills field, Claude generates a delegation message based on the situation. The delegation message can change depending on the context.

While it can change flexibly, it is not easy to determine if unexpected behavior is due to poor sub-agent definition or the influence of the context.

Additional Loading

Both load CLAUDE.md. Sub-agents with a skills field also load preloaded skills.

If you only read this explanation, it seems like there is no difference, but in reality, a major difference occurs. I will explain this in the next section.

Differences in Skill Loading

For skills, only the description is initially loaded in the main Claude Code, and the subsequent content is loaded as needed.

What about skills within a sub-agent? ...This is where there is a major difference.
The official documentation states:

The full content of each skill is injected into the sub-agent's context, not made available only for invocation. Sub-agents do not inherit skills from the parent conversation. You must explicitly list them.

What is important here is that the "full content" is injected into the context. Depending on the skill design, if the entire definition is injected, it can become noise.

	Skill's context:fork	Sub-agent with skills field
Skill Loading	Lazy (description → as needed)	Immediate (full content injection)
Context Efficiency	High (only what is needed)	Potential for low efficiency (everything included)
Skill Inheritance from Parent	All are usable as it is the parent	Not inherited (only explicitly stated skills)

By the way, the release order for each feature is as follows:

1. Sub-agent feature (July 2025)
    ↓
2. Skill feature (October 2025)
    ↓
3. Addition of context:fork and skills field (January 7, 2026)

Looking at the background and functional constraints, I interpreted the skills field as a kind of feature for backward compatibility to make it easier to introduce skills into projects that were already built primarily around sub-agents.

Conclusion: Which one should you choose?

For new projects → Recommend using skill's context:fork

• Skills-centric unified management is possible.
• It is easier to benefit from the ecosystem (other people's skills, plugins, etc.).
• There are fewer constraints compared to sub-agents with a skills field.
• Future feature enhancements are also more likely to come to the skill side.

For projects where sub-agents are already well-built → Introduce skills field

• There is no return that justifies the cost of migrating to context:fork.
• If you need skills, incorporating them via the skills field makes the operation equivalent.
• Although there are slight constraints, if the sub-agent is already complete, it is not worth discarding it.

Summary

• These two approaches are presumed to have been born from historical circumstances for compatibility.
• For new projects, context:fork is recommended.

If you find it difficult to see the difference even after reading the official documentation, it is because, as the official text says, they are using the same foundation.
If you are spending time wondering which to choose, start with context:fork.

Reference Links

• Running skills in a sub-agent
• Preloading skills into a sub-agent