委托
协调器的上下文是贯穿整个会话的唯一窗口。它读取的每个文件和持有的每个命令输出都是判断预算的支出。子代理每个任务会获得一个全新的窗口，因此协调器负责路由、定义完成标准并进行判断；代理则负责读取、运行和写入。
两种角色
每次分派的提示都以 Your ROLE_TYPE is sub-agent. 开头。这一行是一个反递归标记：继承此技能的子代理不得再进行分派。如果你的提示是这样开始的，请在此处停止，并遵循 references/sub-agent-contract.md。否则，你就是委托者，本文件的其余部分对你适用。
何时适用
任何涉及文件变更、原因调查、事实收集、错误修复或工作审查的请求——无论规模大小——以及当你即将自己读取源代码或运行诊断工具而不是将其委托出去时。“只有两行代码”也要委托。唯一的例外是：本次操作中对你刚编辑过的单个文件进行的检查。
在工作进行中也适用：判断子代理的报告（参见裁决），重新分派某个阶段，或泛化用户命名的模式实例（参见模式扩展）。
当答案已经存在于你的上下文中且无需修改文件时，直接内联回答。
分解
将请求拆分为多个阶段。仅保留那些会产生工作的阶段；不要填充无关内容。
| 阶段 | 产出 |
|---|---|
| 读取 | 工作所依赖的材料，定位并读取 |
| 收集 | 外部事实：文档、现有技术、当前系统状态 |
| 处理 | 分析和所选方案 |
| 验证 | 对照实际代码和环境检查所选方案 |
| 写入 | 变更内容 |
| 校验 | 检查、类型检查、构建结果 |
| 测试 | 测试运行，以及覆盖变更的新测试 |
| 报告 | 变更内容及证据 |
| 审查 | 对结果的独立评判 |
一些常见形态有专门的处理方式：
- 错误修复 → references/fix-cycle.md：在更改前重现问题。
- 跨多个目标的相同编辑 → 一次
处理分派决定变更；N 次通用分派应用变更；一次审查分派进行检查。参见 parallel-work。
分派
- 每次分派一个阶段。一个阶段可以扩展到 N 个目标（N 次分派，相同阶段）；不能与另一个阶段混合。
- 独立的各次分派在同一轮中一起发送，以便并发运行。仅在一个分派需要消耗另一个分派的结果，或者两个分派要写入同一文件且无法隔离时，才进行串行化。
读取/收集/处理的结果放入文件，而非你的上下文。将路径传递给下一阶段；不要转发内容。
选择代理
根据任务对代理的要求进行分类，而不是根据其名称：
- 专家 — 任何描述与阶段领域匹配的代理。获得观察结果、成功标准和上下文。绝不获得实施步骤。
- 通用 —
general-purpose（或类似的工具链）和Explore。获得规定的实施内容：精确的编辑、精确的文件、精确的验证。Explore仅用于精确匹配搜索。 - 审查者 — 对于
审查阶段，选择一个与编写者不同的代理，优先选择该领域的审查型或审计型代理。
当没有合适的专家时，使用规定的任务分派给通用代理。
两个提示都以相同的两行开头——将它们逐字复制到所选模板的第一行：Your ROLE_TYPE is sub-agent. Follow the sub-agent contract at <absolute path to references/sub-agent-contract.md>.
提示——专家模式
PHASE: <阶段名称之一>
TASK: <一句话>
OBSERVATIONS:
- <您上下文中已有的事实：用户陈述、先前的 STATUS 报告、逐字的错误信息、已知的文件:行号>
DEFINITION OF SUCCESS:
- <可衡量的结果>
- <验收标准>
- <如何验证——一个命令及其预期结果，或将要检查的审查者>
DELIVERY:
- 将任何超过一行的内容写入 .tmp/scratch/reports/<YYYYMMDD>-<slug>.md 并返回路径。
CONTEXT:
- Location: <查找位置>
- Scope: <边界>
- Constraints: <用户强制要求；要遵循的现有模式>
- Commands: <项目的验证/测试质量门，或“发现此项目定义的门”>
ECOSYSTEM CONTEXT: （如果为空则省略此部分）
- <代理无法读取的会话事实：已认证的 CLI、正在审查的 PR、在同一文件上活跃的另一个代理>
YOUR TASK:
<下面表格中对应阶段的行，逐字复制>
阶段行对应 YOUR TASK：
| 阶段 | 行 |
|---|---|
| 读取 | 定位并读取此工作所依赖的材料。将精确的路径和引用的内容写入交付文件；不要遗漏后续阶段可能需要的细节。不编辑任何内容。 |
| 收集 | 收集 CONTEXT 中命名的外部事实。在交付文件中记录每个事实及其来源。不编辑任何内容。 |
| 处理 | 分析 OBSERVATIONS 中路径下的材料。选择一种方案；记录该方案及为何排除其他备选方案。不编辑任何内容。 |
| 验证 | 将所选方案与 CONTEXT 中的实际代码和环境进行对照检查。记录其成立之处和失败之处。不实施任何内容。 |
| 写入 | 按照 DEFINITION OF SUCCESS 进行变更。只触及 CONTEXT Scope 内的文件。 |
| 校验 | 运行 CONTEXT Commands 中的命令，或发现此项目的检查/类型检查/构建门，并说明运行了哪些。报告精确输出，包括通过和失败。沉默的失败就是失败。 |
| 测试 | 运行 CONTEXT Commands 中的测试调用，或发现它并说明运行了哪个。添加覆盖变更的测试。报告精确输出。 |
| 报告 | 说明变更了哪些内容及其证据：文件、命令、输出。不做出证据不支持的声明。 |
| 审查 | 根据 DEFINITION OF SUCCESS 评判 OBSERVATIONS 中路的结果。报告差距、矛盾、无根据的声明。不修复任何内容。 |
填充规则的注意事项：
- 如果某个部分无法用您上下文中已有的内容填充，则省略该部分，不要凭空发明。空的 OBSERVATIONS 或 ECOSYSTEM CONTEXT 是有效状态；猜测则不是。
- OBSERVATIONS 是传递的：仅包含您上下文中已有的内容。为了填充它而进行读取、grep 或运行命令属于预收集；代理将使用全新的窗口来完成这些。
- 将观察结果陈述为事实（“exit code 1”，“错误文本是：…”）。如果您持有假设，请标注：
要验证的假设：…。 - Constraints 是结果和边界，绝不是步骤。在 Commands 中命名项目自身的门是一个约束，而不是一个步骤。
- 不要提及代理会继承的内容：仓库约定、工具链、“自由探索”、“使用可用技能”。这些存在于项目的代理指令中。仅在代理必须加载某项技能且它不会自动加载时才命名该技能。
- 路径：以代理从其自身工作目录解析的方式编写；仓库内部使用相对路径，对于通过符号链接访问的任何内容，使用符号链接形式（而不是解析后的目标）。
提示——通用模式
PHASE: <write | validate | test | read>
TASK: <精确指令——要进行的编辑、要查找的模式、要运行的命令>
FILES:
- <精确路径>
DEFINITION OF SUCCESS:
- <验证命令及其预期结果>
DELIVERY:
- 在报告中包含验证输出。
裁决
报告都是声称。对于每份报告：
- 检查证据是否支持结论。“测试通过”而没有命令输出不是证据；重新分派以获取输出。
- 判断返回的工作；不要重新推导。重新读取代理读取过的内容会浪费通过分派节省的上下文。
- 两份报告冲突 → 找到可证伪的声明并分派一项检查。信心不是打破平局的因素。
PARTIAL→ 重新分派剩余部分，精确说明还需要做什么。BLOCKED因为缺少输入 → 提供输入并重新分派。尝试后仍然BLOCKED→ 更改方法或升级给用户；不要重新发送相同的提示。
对于相同的差距，最多重新分派同一阶段两次。之后，停止并向用户报告 BLOCKED，并说明差距。
每个更改代码的请求都要由一个与编写者不同的审查者进行独立审查。
模式扩展
用户指向某个坏味道、错误或缺失检查的一个实例，实际上是在命名一个模式。除非他们说“仅此一个”，否则：对整个文件或模块进行模式审计，报告找到的实例，并在修复超出命名文件范围的问题之前与用户确认。
参考
- references/sub-agent-contract.md — 被分派的代理遵循的指南。
- references/fix-cycle.md — 错误修复分派的先重现再修复流程。
- parallel-work — 扇出、扇入、制造者/检查者、竞赛、带有上限的循环；也指向 Claude Code 工具链机制。
- 如果安装了
orchestrator-discipline：协调器可以读取和运行的内容；由钩子强制执行。 - 如果安装了
process-siren：将决策点写为可求值的 Mermaid 菱形图。