用途
subagent-dev 是一个用于执行多任务实现计划的技能。它的核心做法是：把实现计划拆解为一个个独立任务，每个任务都交给一个全新的子代理（subagent）来执行，并在任务完成后进行两阶段审查——先验证规格符合性，再审查代码质量。
它与 ralph-loop 的关系是：ralph-loop 覆盖从规格（specs）到计划（plan）、实现（implement）、测试（test）的完整流程；subagent-dev 则是其中“实现”阶段的执行模式，强化了 ralph-loop 中“用子代理逐个完成任务”的原则。
主要能力
任务循环流程
整体流程为：读取计划 → 提取全部任务 → 对每个任务重复以下步骤 → 全部完成后进行最终代码审查与分支收尾。
每个任务的循环：
- 派发实现子代理（提供任务全文与上下文）。若子代理有疑问，先回答再重新派发；子代理负责实现、测试、提交与自审。
- 派发规格验证子代理。若发现规格不一致，由实现者修改后重新验证；通过则进入下一步。
- 派发代码质量审查子代理。若发现质量问题，由实现者修改后重新审查；通过则批准。
- 标记该任务完成。
两阶段审查
- 第一阶段：规格验证。检查代码是否与需求一致、是否遗漏功能、是否添加了不必要的功能、规格中列出的所有条目是否都已实现。
- 第二阶段：代码质量。检查重复代码、命名、类型覆盖、错误处理、边界情况、性能问题、安全问题。
之所以分两阶段：规格验证回答“是否做对了东西”（What），代码质量回答“是否做得好”（How）；合并成一次审查容易两者都漏掉。
子代理提示词结构
技能给出了实现者与规格审查者的提示词模板。
实现者提示词包含：任务（从计划中提取的任务全文）、上下文（相关文件、架构、约束条件）、约束（只修改本任务范围、TDD 先写测试后实现、编写提交信息、包含自审结果）、输出（实现摘要、测试结果、自审发现）。
规格审查者提示词包含：原始规格（任务需求全文）、验证对象（已实现代码的 git diff 或文件列表）、检查清单（所有需求是否实现、是否有不必要的额外功能、边界情况是否处理）。
使用方式
按上述任务循环执行：控制器先读取计划并提取任务，然后为每个任务依次派发实现、规格验证、代码质量审查三类子代理，根据审查结果决定是否让实现者修改并重新审查，最后完成整体收尾。控制器需要提前准备任务上下文。
适用场景
适用于执行包含多个任务的实现计划，尤其是重要功能的实现。技能本身指出：成本与质量收益相比，质量收益更大，因此在实现重要功能时尤为必要。
成本与限制
- 每个任务需要 3 次子代理调用（实现 + 规格审查 + 质量审查）。
- 需要控制器做准备工作。
- 审查循环会产生额外调用。
护栏（Guardrails）
- 最小权限原则：只授予子代理完成该任务所需的文件/目录访问权限，禁止访问整个工作区；提示词中需明确包含“访问允许范围”部分。
- 禁止文件删除/覆盖命令：除非明确允许，不指示子代理执行 rm、rmdir 或文件覆盖操作；需要破坏性操作时由控制器直接执行，或经 Master 批准后进行。
- 限制外部网络访问范围：在提示词中明确子代理需要访问的外部 URL/API，禁止范围外的网络访问；禁止从未经验证的外部来源下载或执行代码。
- 默认超时 300 秒：派发子代理时若未指定超时，默认应用 300 秒；长时间任务需包含中间进度报告的检查点。