長い調査を Agent Skills の「context: fork」で親コンテキストから隔離するAdding `context: fork` to SKILL.md lets supporting hosts run an agent skill in…

Agent Skills, the emerging convention for packaging reusable instructions and tooling for AI coding assistants, is gaining a mechanism to keep long-running research from overwhelming a conversation. A blog post on Qiita explains how adding `context: fork` to a SKILL.md file lets supporting hosts run an agent skill in an isolated context, so that lengthy investigation tasks do not pollute the parent conversation thread. For developers who routinely delegate deep, multi-step research to an assistant, this addresses a practical and recurring pain point.

To understand the change, it helps to know what SKILL.md is. Agent Skills are typically distributed as a folder containing a SKILL.md file, which pairs YAML-style frontmatter, such as a name and a description, with a Markdown body that spells out how the skill should behave. The host application, meaning the tool that actually runs the model, reads this file and decides when and how to invoke the skill. Because the format is just text and metadata, it is portable across hosts that agree to interpret the same fields.

The new field, `context: fork`, is a directive to those hosts. When present, a supporting host is expected to execute the skill in a forked or separate context rather than inside the ongoing conversation. In practice this appears to mean the model works in an isolated area for the skill, performs its steps there, and then returns only the relevant result to the parent thread. The intermediate reasoning, tool calls, and large outputs generated along the way stay out of the main history.

The motivation is context window management. Every model has a finite context window, and long research tasks tend to consume it quickly, since each search result, file read, or chain of reasoning adds tokens that persist for the rest of the session. As that history grows, the assistant can lose track of the original goal, respond more slowly, or hit hard limits. By isolating the heavy work, `context: fork` is intended to keep the parent conversation lean and focused on outcomes rather than the mechanics of getting there.

The pattern is conceptually similar to the subagent and task-delegation approaches found in other agent frameworks. Tools such as Claude Code and various orchestration layers already let a primary agent hand off a bounded job to a secondary process that reports back a summary. Framing that behavior as a declarative field in SKILL.md is notable because it moves the decision from application code into the skill definition itself, allowing a skill author to signal that their workflow is best run in isolation.

An important caveat, which the source emphasizes, is that the behavior depends on the host. The phrase "supporting hosts" indicates that `context: fork` is only meaningful where the runtime has implemented it; a host that does not recognize the field would likely ignore it and run the skill inline as usual. Skill authors therefore cannot assume isolation everywhere and should design their instructions to degrade gracefully.

Some background on the ecosystem is useful here. The SKILL.md convention grew out of efforts to make agent capabilities modular and shareable, rather than hard-coding prompts into each application. This item sits in the GitHub Copilot category, and the broader trend across assistants, including Copilot, Claude, and others, is toward standardized, file-based extension formats that a growing number of hosts can consume. Reducing lock-in to a single vendor is part of the appeal, since a well-formed skill folder can in principle be reused wherever the format is honored.

For teams, the most immediate benefit is reliability during long tasks: code audits, dependency investigations, log analysis, or documentation surveys that would otherwise crowd out everything else in a session. Placing such work behind a forked context lets the main thread retain room for follow-up questions and iterative refinement.

As with any young convention, the details are likely to evolve, and exact semantics, such as how results are returned, how much state is shared, and which hosts comply, may differ between implementations. Developers experimenting with `context: fork` should verify their specific host's support and test how summaries flow back before relying on it in production workflows. The author, writing from an architect's perspective, presents the field as a pragmatic tool rather than a finished standard and invites corrections, a reminder that this space is still settling.