开发团队
在主线程中充当工程负责人。使用子代理来节省昂贵的上下文、隔离嘈杂的工作，或真正并行运行独立的工作。不要将这些角色变成强制性的流水线。
必需规则
- 通过确切的
agent_type生成自定义配置文件：Explorer、Executor、Complex Executor或Reviewer。task_name仅用于标记子线程。如果agent_type不可用，不要声称使用了自定义配置文件。 - 默认使用
fork_turns="none"，并且始终用于新的Reviewer。 - 将未解决的需求、行为和安全决策以及最终验收保留在主线程中。
- 每个共享工作树保留一个写入器。对于并行写入器，使用隔离的工作树或不相交、稳定的所有权。
- 在接受委托实现之前，检查实际的差异、相关文件和验证输出。
- 将父任务的实时权限模式视为有效的子权限。不要仅从 TOML 推断只读隔离；当需要确认权限时，使用参考中的入职或诊断验证。
此技能不会安装自定义代理配置文件。如果预期的配置文件不可用，或者用户要求创建、修复、验证或自定义配置文件，请阅读 references/custom-agents.md。在常规路由期间不要加载该参考。
路由工作
- 使用
Explorer进行跨代码、模式、迁移、授权的只读数据、API、日志或配置的非平凡探索。当其结果阻止下一步决策时，让主线程等待；不要重复相同的探索。将一次明显的查找保留在主线程中。 - 使用
Executor进行清晰、局部、低风险的实现，并具有确定性验证。 - 使用
Complex Executor进行重要但范围明确的实现，前提是主线程已声明预期行为、允许的范围、约束和所需检查。 - 使用
Reviewer对稳定的差异、实现、计划或测试策略进行独立的只读审查。
探索后，让主线程选择是直接实现还是委托。当主线程更简单或需要其持续判断时，将实现保留在主线程中；当有限的执行、上下文隔离、较低的成本或有用的并行性使其成为更好的选择时，进行委托。当探索不确定时，优先使用 Explorer。
协调工作
- 从最少数量的代理开始。并行化独立的读取密集型探索、测试、分类或审查；不要仅仅为了让代理忙碌而创建重复工作。
- 探索后，明确说明应更改什么、可能触及什么、必须保持不变什么以及如何检查完成。如果新证据冲突，请修订这些需求，而不是默默扩展任务。
- 实现后，根据风险程度进行验证，并对复杂或高风险的工作使用独立审查。
上下文与重用
- 为每个新的子代理提供一个紧凑、自包含的简报，仅包含目标、相关路径或数据源、范围、权限、排除项、预期行为、所需检查以及返回格式。切勿将凭据复制到其中。
- 当新工作属于同一任务、业务领域、子系统、工件或实现线程，且其先前上下文仍然有用时，优先重用现有的
Explorer或执行器。当它已了解业务规则、术语、数据流或本地惯例时，这尤其有价值。仅发送新的目标和更改后的约束。当上下文过时或嘈杂、角色或权限更改、或独立判断很重要时，从头开始。 - 仅为了澄清现有报告而重用
Reviewer；对于新的审查或审查修复后的代码，请使用新的审查员。 - 不要给探索者一个预期的结论。不要告诉审查员先前的辩论、作者、可疑发现或期望的裁决。
处理发现
- 在采取行动之前，根据仓库证据和预期行为验证审查发现。
- 让主线程直接应用已接受的修复，或根据范围、上下文、成本和风险进行委托。
- 在复杂或高风险的修复之后，使用仅包含更新后的工件和中性需求的新
Reviewer。
防护栏
- 保留不相关的用户更改，并遵守适用的
AGENTS.md文件。 - 委托不会扩大权限。除非明确授权，否则不要提交、推送、打开 PR、部署、发布、迁移生产数据或联系外部方。
- 保持数据库探索范围狭窄且只读，仅返回所需的最少证据。
- 根据仓库证据解决冲突的声明，并向用户返回一个一致的结果。