TL;DR: An inline Skill adds instructions to the main conversation, shares its existing history, and continues on the same agent loop. With context: fork, the rendered Skill becomes a new subagent's task. The subagent has its own context, agent configuration, and tool boundaries; its result returns to the caller. Inline suits knowledge and workflows requiring ongoing collaboration. Forking suits self-contained, lengthy tasks whose intermediate work can be summarized.

Part 5: From Arguments to Dynamic Context took SKILL.md through rendering. The next step is not to execute a fixed function. It is to decide: Do these instructions go to the current Claude or to a new worker?

inline rendered Skill → current conversation fork rendered Skill → new subagent context → result to caller

Both use the same Skill file format, but they create very different information flows.

Inline: add a method to work already in progress

By default, a Skill expands in the current conversation. Imagine the user has explained the release, Claude has inspected the diff, both have agreed to check staging only, and the user invokes /release-check v2.4.0.

An inline Skill can use all that existing information immediately: the user's goal, files already read, decisions made, and tool results. Its instructions join an ongoing task. Claude need not reconstruct the situation; the Skill adds a method to the agent already doing the work.

Inline is appropriate for:

  • Reference-style Skills that enrich current work with domain knowledge.
  • Processes requiring repeated user interaction.
  • Tasks whose stages share a great deal of context.
  • A Skill that forms only one part of a larger task.
  • Work that must keep referring to decisions and tool results in the main conversation.

The benefit is continuity. The cost is that the Skill body, subsequent reads, and intermediate tool results all continue growing the main context.

Fork: turn the Skill body into a delegated task

Set context: fork in frontmatter:

--- name: deep-release-audit description: "Audit a candidate release in depth" context: fork agent: Explore ---

Claude Code starts a separate subagent. The rendered SKILL.md becomes the task assigned to that agent rather than an addition to the main conversation:

Main conversation “Audit v2.4.0” ↓ invoke forked Skill Subagent context ├─ agent system prompt ├─ rendered Skill content ← task ├─ files it reads ├─ tool results it produces └─ final findings ↓ Main conversation receives the result

Despite the word fork, this is not a copy of the main message history. The subagent gets a fresh context window. It does not automatically see the full conversation, every file the main agent read, or every other Skill it invoked. It receives the Skill task, its chosen agent environment, and the base project context supplied for that agent type.

A forked Skill must be a complete task

Consider a reference Skill containing only API conventions:

This project's APIs use a consistent error format, and list endpoints must paginate...

Inline, Claude can apply those conventions to the endpoint it is already editing. Fork it, and the new subagent has rules but no assignment. Which file should it review? What endpoint should it design? What should it return?

A forked Skill must specify:

  • The object to work on.
  • The action to perform.
  • Where inputs come from.
  • What counts as done.
  • What to return.

For example:

Review the API file named in $ARGUMENTS: 1. Find its endpoints and schemas. 2. Compare them with this project's API conventions. 3. Check compatibility, error format, and pagination. 4. Return issues ordered by severity, with file references.

An inline Skill can supply knowledge; a forked Skill must stand alone as a task.

Arguments carry the handoff

The main conversation might already establish “staging only, not production, target v2.4.0.” A forked subagent does not know those facts simply because they occurred in main history. Necessary information must cross the delegation boundary: through $ARGUMENTS, dynamic context, fixed instructions in the Skill, or a clear task input assembled by the caller.

Implicit state in main conversation ≠ Explicit input to the subagent

If a forked Skill repeatedly depends on “you should remember what I said earlier,” its task boundary is poorly packaged. It may be better inline.

agent chooses the work environment

context: fork requests an independent context. The agent field chooses who performs the task:

  • Explore for read-only code research.
  • Plan for an implementation plan.
  • general-purpose for broader tool use.
  • A custom agent with project-defined model, tools, and system prompt. 
context: fork agent: Explore

The division is:

Skill → what to do this time, workflow, deliverable Agent → role, model, tools, permissions

The same research workflow can use different agent environments. The same reviewer agent can receive different Skill tasks. Keeping role and one-off task separate prevents both from being fused into one Markdown file.

Explore and Plan start lighter

The Claude Code Skills documentation notes that built-in Explore and Plan agents start without CLAUDE.md and Git status to conserve context. Choosing agent: Explore solely because it can read files may therefore omit essential constraints that exist only in CLAUDE.md.

Keep generally applicable project rules where they belong, but repeat any constraint essential to the forked task's success in the Skill itself. Do not rely on an agent implicitly inheriting the main conversation. Greater context isolation requires a clearer task contract.

Forking isolates process, not total cost

Suppose an audit reads 80 files and produces many search results. Inline, that intermediate work accumulates in the main conversation. Forked:

Subagent: 80 files + search results + reasoning ↓ summarize Main context: findings and evidence summary

The main context is protected, but computation is not free. The subagent consumes input tokens, may reread project material it does not know, and adds launch and result-handling latency. An excessively long return still occupies main context.

Forking puts the process in a more appropriate context; it does not create a free second brain. The current docs also allow forked Skills to run in the background by default, with background: false when the caller needs the result before proceeding.

The reverse direction: preload Skills into an agent

So far, context: fork means a Skill selects a worker. Claude Code also supports the inverse: a subagent definition can list skills it should start with:

--- name: code-reviewer description: Review the current changes tools: Read, Grep, Glob skills: - api-conventions - security-guidelines ---

In this arrangement:

Subagent definition → role and system prompt Delegation message → task this time Preloaded Skills → knowledge the role needs at startup
Pattern System prompt Task Role of the Skill
Skill with context: fork Selected agent Rendered SKILL.md Defines this task's workflow
Subagent with skills Subagent definition Delegation from caller Preloads knowledge for that role

The first means “this capability needs a worker.” The second means “this worker needs this knowledge for its assignments.”

Preloading bypasses metadata routing

In an ordinary main session, a Skill's description is available first; its body loads only on activation. Listing a Skill in a subagent's skills field makes a stronger assertion: this agent needs it every time it starts.

The complete content is injected at startup, not merely its name and description. That improves consistency for specialist roles, but creates a fixed context cost. A reviewer that always needs security guidelines is a good candidate. A reviewer that only occasionally processes PDFs should not preload a large PDF Skill for every task.

Preloading promotes an on-demand capability into standing role knowledge. Do it because the responsibility is stable, not merely because Claude might sometimes forget to invoke the Skill.

Preloading is not a Skill-tool allowlist

The subagent documentation distinguishes skills from access to the Skill tool. The field preloads specified bodies; it does not mean “these are the only Skills this agent may invoke.” Without preloads, an agent may still discover and invoke available Skills during execution. To restrict access, configure its tools, disallowed tools, permissions, or Skill access rules separately.

Preloading knowledge also does not grant every operating-system or external-system permission mentioned in that knowledge. Information and enforcement are different layers.

Choosing inline or fork

Question Inline Forked subagent
Needs full main-conversation history Strong fit Does not inherit it
Needs frequent user back-and-forth Strong fit More cumbersome
Produces many intermediate reads and logs Grows main context Can isolate them
Task must be self-contained Not necessarily Yes
Only a summary is needed Possible, but process stays in main Strong fit
Needs specialized tools or model Uses current agent environment Choose an agent configuration
Mainly reference knowledge Strong fit Often no independent task
Small, latency-sensitive edit Strong fit Launch overhead

The choice is not only what a Skill does, but where its method unfolds: inline joins the current line of thought; fork delegates a task to an independent worker. A Skill invoking an agent is task-driven; an agent preloading Skills is role-driven.

Up next

Inline or forked, the work eventually calls tools. A Skill can pre-approve some calls, exclude tools, or register lifecycle hooks; project Skills also interact with workspace trust. Part 7 separates four boundaries: invoking a Skill, accessing a tool, skipping approval, and being truly isolated.

References