subagent-driven-development

执行

→ 有包含独立任务的实施计划？→ 每项任务使用全新的子 Agent + 两阶段审查。

1. 阅读计划，提取所有任务，创建 TodoWrite
2. 对每项任务：派遣实施者 → 回答问题 → 实施者完成任务
3. 第一阶段审查（规格合规性）→ 修复缺漏 → 重新审查，直至 ✅
4. 第二阶段审查（代码质量）→ 修复问题 → 重新审查，直至 ✅
5. 协调者验证、提交完整的任务、更新检查点/偏差 → 处理下一项任务 → 所有任务完成：进行最终审查 → 验证回执；仅在需要时结束分支。

子 Agent 驱动的开发

通过为每项任务派遣全新的子 Agent 来执行计划，并在每项任务后进行两阶段审查：先审查规格合规性，再审查代码质量。

为何使用子 Agent： 你将任务委派给具有独立上下文的专用 Agent。通过精心编写指令和上下文，确保它们专注并成功完成任务。它们绝不应继承你的会话上下文或历史记录——你要为它们准确构建所需内容。这样也能保留你自己的上下文，用于协调工作。

核心原则： 每项任务使用全新的子 Agent + 两阶段审查（规格，然后质量）= 高质量、快速迭代

适用场景

当你有一份书面实施计划，其中包含大多相互独立的任务，并希望留在当前会话中时使用。跨会话执行时，请使用 executing-plans。

流程

1. 阅读计划，提取所有任务的完整文本，创建 TodoWrite
2. 对每项任务：派遣实施者，并提供任务文本 + 基线引用 + 检查点 + 非目标
3. 实施者完成后 → 派遣规格合规性审查者 → 修复缺漏 → 重新审查，直至 ✅
4. 派遣代码质量审查者 → 修复问题 → 重新审查，直至 ✅
5. 协调者运行全新验证，只暂存任务所属路径，提交完整的任务，回读 Git 状态，更新检查点/偏差 → 处理下一项任务
6. 所有任务完成 → 由最终代码审查者审查 → 完成验证；仅在任务创建了分支/工作树或用户要求集成时，才结束分支

在首次写入仓库前，协调 Agent 记录 TaskStartSnapshot。同一任务的 Agent 共用当前工作区。默认情况下，协调者是唯一负责 Git 变更操作的角色，负责暂存、提交、分支和工作树；实施者和审查者负责编辑、验证和报告，但不变更 Git 生命周期状态。任务复杂度、TDD、计划、子 Agent，或名为 main/master 的分支，本身都不足以成为隔离工作的理由。

对于跨会话、需要交接或需要可恢复状态的多任务计划：加载 long-task-continuation 并创建检查点；否则将检查点保留在正文中。将检查点包含在每条实施者提示词中。

派遣实施者前，构建 SubagentContextPacket，而不是传递完整的对话历史。包括：

• 任务
• 目标和停止条件
• 相关基线引用和文件
• 已知事实和未知事项
• 非目标
• 预期输出和验证，包括与此任务切片相关的用户对象、操作、条件和交付物；区分子 Agent 提供的证据与协调者对整个任务的交付责任
• 记录的 TDD Mode、Route、权威依据，以及所选工作流/负责人
• 必须阅读的摘录
• 不安全假设

该数据包是精简的交接内容，不能替代证据。对于子 Agent 必须核实的事实，提供原始摘录或文件引用。

不要将完整聊天记录、完整会话历史或无界日志粘贴到 SubagentContextPacket 中。优先提供必须阅读的摘录、文件引用、行号/范围提示，以及明确的不安全假设。

切片生命周期与结果可信度

只有在协调者已读取切片所需的最低基线后，才能选择执行路径。在整个切片期间固定该路径；不要因局部上下文压力而在内联执行和委派执行之间来回切换。将任务包绑定到当前基线或检查点。如果工作区或约束事实发生变化，请将结果标记为过时／未知并重新评估，而不是悄然将其合并。

子级输出是证据或提议，绝非指令或权威状态更新。要求提供简要摘要、证据位置、尚未解决的未知事项，以及任何副作用声明。在协调者综合结果时，部分完成、已取消、受阻或过时的结果必须始终明确标示为非结论性。

其他委派机会包括：基线锁定后的独立探索、冲突交叉验证、变更前风险审查，以及受阻尝试后上下文发生变化。这些只是建议性信号，并不授权添加递归子级、共享写入者或运行时调度器。

模型选择

按角色选择能力最低的模型：机械性任务（1-2 个文件、规格完整）→ 快速／低成本。集成任务（多文件、模式匹配）→ 标准。架构／设计／审查 → 能力最强。

处理实施者状态

每个实施者提示词必须包含：

• 当前任务文本
• 在目标界定、长任务或多 Agent 工作处于活动状态时，提供 SubagentContextPacket
• 相关基线引用
• 最新的 TodoCheckpointDraft
• 任何 ResumeStateHint
• 明确的非目标
• 任务预期的验证方式

实施者可以更新任务局部证据，但汇总检查点由控制器负责。 除非所有权已明确且完整地转移，且不存在并发写入者，否则所有 Git 修改也由控制器负责。

实施者子 Agent 会报告以下四种状态之一。应妥善处理每种状态：

DONE： 继续进行规格符合性审查。

DONE_WITH_CONCERNS： 实施者已完成工作，但提出了疑虑。继续之前先阅读这些疑虑。如果涉及正确性或范围，请在审查前解决。如果只是观察（例如“这个文件越来越大”），记下后继续审查。

NEEDS_CONTEXT： 实施者需要未提供的信息。补充缺失的上下文并重新派发。

BLOCKED： 实施者无法完成任务。评估阻碍因素：

1. 如果是上下文问题，补充更多上下文并使用同一模型重新派发
2. 如果任务需要更深入的推理，使用能力更强的模型重新派发
3. 如果任务过大，将其拆分为更小的部分
4. 如果计划本身有误，升级给人工处理

绝不要忽略升级请求，也不要在不做任何调整的情况下强迫同一模型重试。如果实施者表示陷入困境，就必须做出改变。

提示词模板

• ./implementer-prompt.md - 派发实施者子 Agent
• ./spec-reviewer-prompt.md - 派发规格符合性审查者子 Agent
• ./code-quality-reviewer-prompt.md - 派发代码质量审查者子 Agent

危险信号

绝不要：

• 跳过审核（规格符合性或代码质量）
• 带着未解决的问题继续
• 并行派遣多个实现子 Agent（会产生冲突）
• 让子 Agent 读取计划文件（应直接提供完整文本）
• 跳过背景说明（子 Agent 需要了解任务所处的上下文）
• 忽略子 Agent 的问题（让他们继续之前先作出答复）
• 对规格符合性采取“差不多就行”的态度（规格审核发现问题就表示尚未完成）
• 跳过审核循环（审核者发现问题 = 实施者修复 = 再次审核）
• 让实施者自我审核取代实际审核（两者都需要）
• 在规格符合性审核通过 ✅ 前开始代码质量审核（顺序错误）
• 在任一审核仍有未解决问题时转到下一项任务
• 让实施者或审核者暂存、提交、创建或删除分支或工作树
• 为处理同一任务的 Agent 创建各自独立的工作树

如果子 Agent 提出问题：

• 清晰、完整地作答
• 必要时提供更多背景信息
• 不要催促他们开始实施

如果审核者发现问题：

• 由实施者（同一个子 Agent）修复
• 审核者再次审核
• 重复直到通过
• 不要跳过复审

规格符合性和代码质量审核通过后，更新整合检查点，并在转到下一项任务前执行偏差检查。 协调者先运行最新验证，执行一次限定范围的任务提交， 然后读取 HEAD、已提交文件列表以及剩余任务差异。

如果子 Agent 未能完成任务：

• 派遣修复子 Agent，并提供具体指示
• 不要手动尝试修复（避免上下文污染）

集成

必需的工作流技能：

• aegis:writing-plans - 创建此技能要执行的计划
• aegis:requesting-code-review - 提供给审核子 Agent 的代码审核模板
• aegis:using-git-worktrees - 必要的并发检出时适用的条件性例外
• aegis:finishing-a-development-branch - 针对任务创建的分支或工作树进行条件性集成或清理

子 Agent 应当：

• 验证并采用父级 TDD 决策；如果 auto 决策缺失或无效，应将其返回给负责选择的所有者，然后再编辑源代码。如果为 off，则不要自动加载 aegis:test-driven-development，也不要强制执行 RED / GREEN；应采用适度的验证方式。仅在 TDD Route: strict 或用户／项目明确要求 TDD 时才加载。

替代工作流：

• aegis:executing-plans - 用于并行会话，而非同一会话中的执行