一、为什么需要选择
每个 Skill 执行时都面临一个二元选择：在主对话上下文中直接运行，还是通过 context: fork 在独立 SubAgent 中运行。两个方向都有代价。
不用 fork 的代价 — 上下文污染：
一个代码审计 Skill 遍历整个项目，产生数万 token 的中间输出（文件内容、搜索结果、分析过程）。这些信息全部留在主对话上下文中，挤占有效空间。后续对话的响应质量随之下降——Claude 被迫在大量不相关信息中寻找关键内容。
滥用 fork 的代价 — 能力丢失：
context: fork 创建的 SubAgent 默认不继承 MCP 工具。如果 Skill 依赖 MCP Server 提供的能力（数据库查询、网页搜索、浏览器操作），fork 后这些工具不可用，Skill 的核心功能无法执行。
这不是"都用 fork 更安全"或"都不用 fork 更方便"能解决的问题。选择取决于具体 Skill 的需求特征。
二、限制与红线
硬约束：SubAgent 不继承 MCP 工具
context: fork 创建的 SubAgent 回退到基本工具集（Glob、Grep、Read、Edit、Bash 等内置工具）。主会话中配置的 MCP 工具在 SubAgent 中不可用。
这是当前的已知限制（GitHub Issue #19526，状态为 Feature Request）。allowed-tools 字段可以列出 MCP 工具名（如 mcp__postgres__*），但实际可用性取决于 SubAgent 的工具继承机制——目前这些工具在 fork 环境中无法被调用。
判断依据：如果 Skill 的核心任务依赖任何 MCP 工具，fork 会导致任务失败。
硬约束：SubAgent 无对话历史
fork 创建的 SubAgent 拥有独立上下文窗口，不访问主对话的历史消息。SKILL.md 的内容成为 SubAgent 的初始 prompt，CLAUDE.md 自动加载。
判断依据：如果 Skill 需要"基于刚才的讨论做 X"，fork 后 SubAgent 无法获取"刚才的讨论"。