What you’ll be able to do
- Explain what context: fork changes about where a skill’s work happens
- Diagnose a session that has “forgotten” early findings as a context-crowding problem
- Decide when a skill should run isolated versus inline in the main session
What you need to know
The symptom: a session that “forgets” what it already found
A codebase-analysis skill runs at the start of a long session, maps the module structure, and reports it in full. The team keeps re-invoking that same skill later — after other work has happened — because it's useful. By the third or fourth invocation, the session can no longer answer questions about what the first invocation found. It starts describing the codebase generically instead of citing the specific modules it already mapped.
The instinct is to blame the model's memory. That's the wrong diagnosis. Nothing was forgotten in the sense of being lost — it's still technically in the transcript, buried under three more copies of the same verbose report, competing for the same context budget as everything else in the conversation.
The fix: run the skill in an isolated context, return only the summary
Setting context: fork in a skill's SKILL.md frontmatter runs that skill in its own subagent context, separate from the main session's conversation. The subagent does its full work — reading files, reasoning through structure — inside that isolated context. Only the skill's final summary is returned and added to the main session.
The main session's context budget now holds four short summaries instead of four long reports saying overlapping things. What the first invocation found is still legible, because it isn't competing with three copies of itself for space.
When isolation is worth it — and when it isn’t
Forking has a cost: the subagent starts without the main session's accumulated context, so it needs enough information handed to it (via the invocation, or by reading files itself) to do its job. That's a reasonable trade for a skill whose internal work is long but whose useful output is short — exactly the codebase-mapping case above.
It's the wrong call for a skill whose output is the point — a skill that drafts a paragraph of release notes doesn't benefit from isolation, because there's no bulky internal work to hide; the draft itself is what the main session needs, in full.
Key concept
context: fork moves a skill’s internal work out of the main session’s context budget and returns only its summary — it fixes crowding, not forgetting.
When a scenario describes a session losing track of something a skill already found — especially after that skill has run more than once — the fix is almost always isolating that skill's execution and shrinking what it reports, not increasing the context window or re-running the skill again.
Practice scenario
Work it through, then open this
Add context: fork to the skill’s frontmatter so it runs in an isolated subagent context and returns only a short summary of its findings. The full analysis still happens — it just no longer accumulates in the main session’s transcript on every invocation. Four short summaries fit comfortably where four full reports crowded each other out.
Build exercise — Decide fork or inline for a set of skills
Intermediate · 20 min
What you’ll learn
- Recognizing the “crowded, not forgotten” pattern from a session transcript
- Matching context: fork to skills with long internal work and short useful output
- Spotting a skill where isolation would cost more than it saves
-
Look at a skill invoked more than once in a long session and check whether its full output is re-appended each time.
- Why: Repeated verbose output from the same skill is the specific pattern context: fork addresses.
- You should see: Either isolated summaries already, or a growing pile of near-duplicate reports.
-
For a skill whose entire value is a short, final draft (not internal research), decide whether forking would help or just add overhead.
- Why: Forking trades away the main session’s accumulated context for isolation — a bad trade when there’s no bulky internal work to hide.
- You should see: A skill like this usually should not be forked.
Exam traps
Assuming a session “forgot” something when it was actually crowded out by repeated verbose output
The information is still in the transcript; it’s competing with duplicates for the same context budget. That’s a crowding problem, not a memory problem.
Forking every skill regardless of whether isolation is needed
A skill whose value is its final short output, with no bulky internal work, doesn’t benefit from isolation and loses the main session’s accumulated context for nothing.
Believing a forked skill shares live state with the main session while it runs
It runs in a separate subagent context and needs relevant information handed to it or gathered itself — it isn’t watching the main session’s conversation live.
Designing a forked skill’s summary as vaguely as its full output
Isolation only helps if the summary that comes back is actually short and specific — a vague one-liner is as useless as the full report it replaced.
Treating context: fork as a performance optimization rather than a context-budget one
Its purpose is keeping the main session’s context legible across repeated invocations, not making the skill run faster.