Feature request: skill frontmatter option to fork with full main-conversation context (like /fork)

Summary

Add a new skill frontmatter option (e.g. context: inherit — naming TBD) that runs the skill in a side conversation with the main conversation's full context inherited, equivalent to invoking /fork at the moment the skill triggers. Today there is no skill-declarable way to get this behavior; users have to manually run /fork themselves.

Real use case

I have a docx-writing skill. During execution it makes heavy MCP / CLI calls (doc-platform MCP for doc creation, file searches, etc.). What I want:

• The skill needs full main-conversation history — it's writing a doc about what we have been discussing, so a clean context is useless.
• The skill's tool-call noise (MCP traffic, intermediate file reads) should not pollute the main conversation context.

/fork is exactly this shape — but it can only be triggered manually by the user, not declared by a skill.

Why the existing options don't cover this

Claude Code currently offers three nearby mechanisms, none of which fit:

1. Skill context: fork — spawns a completely clean-context subagent. Great for independent tasks like code review, wrong fit when the skill needs to know what the main conversation has been about.

1. /fork slash command — has the right semantics (inherit full context, isolate execution) but is user-triggered only; a skill cannot declare it.

1. Custom subagent + bundled skill + bundled MCP — superficially the obvious workaround if clean-context isolation were acceptable: define a docx-writing subagent that preloads the skill via skills: [...] and bundles the MCP tools. In practice it breaks down on a routing problem that I do not think has a clean solution today:

• To make the subagent useful, its description has to describe the user-facing capability ("write a docx based on the current discussion").
• But the skill's description describes the same capability — that is what makes the skill matchable in the first place.
• With both visible to the routing model, selection between "invoke the skill directly" and "delegate to the subagent" is genuinely ambiguous, and in practice the model picks inconsistently.
• The intended way out is disable-model-invocation: true on the skill so the skill is only reachable through the subagent's preload — that hides the skill from main-session routing entirely and leaves the subagent's description as the only matchable surface. That is exactly the path #51007 reports as broken: the same flag also disables the subagent's own skills: preload, so the subagent ends up loaded without the skill body it was supposed to bundle. With true unusable, the skill has to stay invocable from the main session.
• The only configuration that "works" today is genuinely silly: leave disable-model-invocation at its default (false), put "NEVER trigger this skill" into the skill's description to deter the main-session model from picking it, and duplicate the real triggering description onto the subagent. The skill stays technically visible to the main session — the whole arrangement is held together by a description that says "ignore me." That is not a workaround, it is a symptom that the feature surface is missing a primitive.

And even if #51007 were fixed and the description-collision went away, this path still does not deliver the "needs main-conversation context" half of the requirement — custom subagents always start clean.

The result: the current matrix forces a choice between "inherit context" (only via manual /fork) and "isolate execution" (only via clean-context fork or subagent), with no way to get both from a skill declaration.

Proposal

Add a skill frontmatter value such as:

context: inherit   # or: fork-with-history, fork-inherit, etc.

Semantics:

• When the skill triggers, behave as if the user just ran /fork: a side conversation is opened with the full main-conversation context.
• The skill's instructions and all subsequent tool calls run inside that side conversation.
• Final result returns to the main conversation; intermediate tool-call traces stay in the fork.

This rounds out the existing context: fork (clean) into a pair: clean fork for independent work, inherit fork for context-dependent isolated work. It also collapses the description-collision problem above — there is no longer a need to introduce a subagent purely as an isolation boundary, so the skill's description is the only routing surface and the routing decision is unambiguous.

Alternative considered

Fix the disable-model-invocation: true × subagent skills: [...] preload interaction (#51007), then document custom-subagent + bundled-MCP as the recommended isolation pattern. This would unblock the description-collision symptom (disable-model-invocation: true would actually work, hiding the skill from main-session routing and leaving the subagent's description as the only matchable surface). But it still does not solve the "needs main-conversation context" half, since custom subagents always start clean. So fixing #51007 is necessary for adjacent clean-context isolation use cases, but not sufficient for this one.

Why this matters now

This feature request and #51007 are independent asks that solve different halves of the matrix:

• This feature is the only thing that unblocks the docx-writing use case above — declaring a skill that both inherits main-conversation context and isolates tool-call traffic in a single primitive. Without it, the only path is the user manually typing /fork before invoking the skill, which defeats the purpose of skills as declarative capabilities.
• Fixing #51007 does not close that gap (custom subagents always start without main-session history), but it makes the orthogonal "clean-context isolation via subagent" path actually workable for adjacent scenarios — and removes the silly description-trick configuration described above.

Resolving both would give users a clean matrix to choose from: context: fork for clean-context isolated work, context: inherit for context-dependent isolated work, and a working subagent path for cases that genuinely want a separate-identity boundary.

Related

• #51007 — disable-model-invocation: true blocks the documented subagent skills: preload, which is what makes the custom-subagent path collapse into the silly configuration described above.
• #51165 — separate context: fork regression on Windows v2.1.113.