多代理开发框架（Multi-Agent Dev）- 免费版

通过为每个任务派发新鲜子代理执行实现计划，并在每步后进行两阶段评审（规格合规+代码质量），实现基础的高质量迭代. 核心原则： 每任务新鲜子代理 + 两阶段评审 = 高质量迭代

输入格式

核心能力

1. 智能任务分解

   • 读取实现计划文件，提取所有任务的完整文本与上下文
   • 创建TodoWrite跟踪所有任务状态，确保进度可见
   • 控制器提供完整任务文本给子代理，不让子代理读取计划文件
   • 输出：TodoWrite任务列表、每个任务的完整上下文包

2. 新鲜子代理执行

   • 每个任务派发全新子代理，避免上下文污染
   • 控制器提供完整任务文本+场景设定+相关文件内容
   • 子代理可提问，控制器回答并提供上下文
   • 子代理遵循TDD流程：实现、测试、提交、自评审
   • 串行执行所有任务，确保安全

3. 基础两阶段评审

   • L0自评审：每次实现后，实现子代理自检
   • L1规格合规：L0通过后，对照规格检查完整性与多余内容
   • L2代码质量：L1通过后，检查代码质量与优秀实践
   • 评审顺序：L0→L1→L2，绝不在L1通过前开始L2
   • 评审循环：评审发现问题→实现者修复→重新评审，直到通过

4. 应急处理

   • 子代理提问时：清晰完整回答，提供额外上下文
   • 评审发现问题：同一实现子代理修复，评审者重新评审
   • 子代理任务失败：派发修复子代理并附具体指令
   • 子代理上下文不足：控制器补充缺失上下文，重新派发

快速开始

1. 确认运行环境满足依赖说明中的要求
2. 在AI Agent对话中调用本技能,提供必要的输入参数
3. 检查输出结果,根据需要进行后续处理

详细的输入输出格式请参考下方章节说明。

使用流程

领先步：确认前置条件并读取计划

确认有明确的实现计划文件，任务相对独立，在当前会话中执行。读取计划文件，提取所有任务的完整文本和上下文，创建TodoWrite.

第二步：逐任务派发子代理执行

对每个任务：

1. 获取任务文本和上下文（已提取）
2. 派发实现子代理，提供完整任务文本+场景设定+相关文件内容
3. 如子代理有疑问，回答问题后重新派发
4. 子代理实现、测试、提交、自评审（L0）
5. 派发规格合规评审（L1），不合规则实现者修复后重新评审
6. 派发代码质量评审（L2），不通过则实现者修复后重新评审
7. 在TodoWrite中标记任务完成

第三步：完成所有任务

所有任务完成后，使用"完成开发分支"流程决定合并或保留分支.

错误处理

示例

示例：钩子安装功能开发

输入： 用户说"使用多代理开发执行这个计划"，计划文件为 docs/plans/hook-feature-plan.md，包含3个任务. 执行过程：

[读取计划文件: docs/plans/hook-feature-plan.md]
[提取所有3个任务的完整文本和上下文]
[创建TodoWrite包含所有任务]
# ...
任务1: 钩子安装脚本
[派发实现子代理，提供完整任务文本+上下文]
# ...
实现者: "钩子应安装在用户级还是系统级?"
你: "用户级(./.config/hooks/)"
实现者: "明白。开始实现..."
[稍后] 实现者:
  - 实现了install-hook命令
  - 添加了测试，5/5通过
  - 自评审: 发现漏了--force标志，已添加
  - 已提交
# ...
[派发规格合规评审]
规格评审: 规格合规 - 所有要求满足
# ...
[派发代码质量评审]
代码评审: 测试覆盖好，代码整洁。通过.
# ...
[标记任务1完成]
# ...
任务2: 恢复模式
[派发实现子代理]
实现者:
  - 添加了verify/repair模式
  - 8/8测试通过
  - 已提交
# ...
[规格评审: 缺失进度报告，多余--json标志]
[实现者修复: 移除--json，添加进度报告]
[规格评审重新评审: 规格合规]
[代码评审: 魔术数字(100)]
[实现者修复: 提取PROGRESS_INTERVAL常量]
[代码评审重新评审: 通过]
# ...
[标记任务2完成]
# ...
... (任务3类似执行)
# ...
[所有任务完成]
完成!

FAQ

Q1：任务之间有依赖怎么办？ 免费版采用串行执行，所有任务按顺序执行。依赖任务需等待前序任务完成后再开始，前序任务的输出作为后续任务的上下文。不确定任务关系时默认串行处理. Q2：评审循环太多导致成本过高怎么办？ 使用L0自评审过滤明显问题，减少L1/L2评审循环。确保实现子代理在提交前充分自检。规格清晰的计划能减少规格合规循环。如果评审循环超过3次，应检查规格明确性. Q3：为什么不让子代理读取计划文件？ 控制器提供完整任务文本而非让子代理读取计划文件，有两个好处：(1) 无文件读取开销，子代理预先获得完整信息；(2) 控制器精确策展所需上下文，避免子代理被无关任务信息干扰.

依赖说明

运行环境

• Agent平台: 支持SKILL.md的任意AI Agent（Claude Code / Cursor / Codex / Gemini CLI等）
• 操作系统: Windows / macOS / Linux

依赖项

API Key 配置

需要配置对应API Key，详见上文环境配置章节

可用性分类

• 分类: MD+EXEC（）

API Key配置方式:

export API_KEY=${API_KEY:?请设置环境变量}

配置后需重启会话或开启新终端生效。API Key应妥善保管,避免泄露到版本控制系统.

已知限制

1. 串行执行无并行加速：免费版所有任务串行执行，不支持选择性并行执行，任务数量较多时耗时较长.
2. 无全局评审：免费版不包含L3全局评审，无法检测跨任务的集成问题与接口对齐问题.
3. 无依赖图构建：免费版不构建任务依赖图，无法自动识别可并行任务，所有任务按顺序执行.
4. 子代理调用成本：每个任务需要实现子代理+2个评审子代理，评审循环增加迭代次数.

升级提示

升级到多代理开发框架专业版即可解锁以下高级能力：

• 选择性并行执行：根据任务依赖关系自动选择并行或串行策略，完全独立任务可并行派发实现子代理，大幅加速开发
• 依赖图构建：自动构建任务依赖图，识别完全独立任务、共享文件任务、有逻辑依赖任务，智能选择最优执行策略
• L3全局评审：所有任务完成后派发全局代码评审子代理，检查整体一致性、集成问题、接口对齐
• 完整应急处理：并行任务冲突自动回退串行、子代理上下文不足自动补充、TodoWrite状态同步检查
• 工作流集成：与git-worktrees（隔离工作空间）、writing-plans（计划创建）、finishing-a-development-branch（分支完成）深度集成
• 红旗防护清单：12项红旗规则确保开发质量，包括分支保护、评审顺序、上下文隔离等
• 评审模板支持：implementer-prompt.md、spec-reviewer-prompt.md、code-quality-reviewer-prompt.md三套专业提示模板

专业版适合需要并行加速、处理复杂多任务开发、或需要全局集成评审的团队和高级用户使用.

输出格式

{
  "success": true,
  "data": {
    "result": "多代理开发框架处理结果",
    "execution_time": "0.5s",
    "metadata": {
      "version": "1.0",
      "processor": "multi-agent-dev"
    }
  },
  "execution_log": [
    "解析输入参数",
    "执行核心处理",
    "格式化输出结果"
  ],
  "error": null
}