# Subagent Driven Development

> 当在当前会话中执行包含独立任务的实施计划时使用

- **Type:** Skill
- **Install:** `agentstack add skill-myswallow-superpowers-lite-subagent-driven-development`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [MySwallow](https://agentstack.voostack.com/s/myswallow)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [MySwallow](https://github.com/MySwallow)
- **Source:** https://github.com/MySwallow/superpowers-lite/tree/main/skills/subagent-driven-development

## Install

```sh
agentstack add skill-myswallow-superpowers-lite-subagent-driven-development
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 子代理驱动开发

每个任务调度一个全新的子代理来执行计划，每个任务后做一次 spec 合规性评审。所有任务完成后，再对整个实现做一次最终代码评审：用 `./code-reviewer.md` 模板调度一个评审子代理，用最强模型（opus）。

**为什么用子代理：** 你将任务委派给上下文隔离的专门代理。通过精确构造它们的指令和上下文，确保它们专注并完成任务。它们绝不应继承你会话的上下文或历史——你为它们构造的恰是它们所需。这同时保留了你自己的上下文用于协调工作。

**核心原则：** 每个任务一个全新子代理 + 每任务 spec 评审 + 收口一次最终代码评审（用 opus）= 高质量、低噪音、快速迭代

**连续执行：** 不要在任务之间停下来跟你的协作伙伴对接。一口气把计划里所有任务都执行完。停下的唯一理由是：你无法解决的 BLOCKED 状态、确实阻塞推进的模糊点，或所有任务已完成。"我该继续吗？" 之类的询问和进度摘要浪费用户时间——他们让你执行计划，那就执行。

## 何时使用

```dot
digraph when_to_use {
    "有实施计划？" [shape=diamond];
    "任务大体独立？" [shape=diamond];
    "保留在本会话？" [shape=diamond];
    "subagent-driven-development" [shape=box];
    "executing-plans" [shape=box];
    "手动执行或先 brainstorm" [shape=box];

    "有实施计划？" -> "任务大体独立？" [label="是"];
    "有实施计划？" -> "手动执行或先 brainstorm" [label="否"];
    "任务大体独立？" -> "保留在本会话？" [label="是"];
    "任务大体独立？" -> "手动执行或先 brainstorm" [label="否 - 紧耦合"];
    "保留在本会话？" -> "subagent-driven-development" [label="是"];
    "保留在本会话？" -> "executing-plans" [label="否 - 平行会话"];
}
```

**vs. Executing Plans（平行会话）：**
- 同一会话（无上下文切换）
- 每任务一个全新子代理（无上下文污染）
- 每任务做 spec 合规评审；所有任务完成后对整个实现收口一次最终代码评审（用 opus）
- 更快的迭代（任务之间无 human-in-loop）

## 流程

```dot
digraph process {
    rankdir=TB;

    subgraph cluster_per_task {
        label="每个任务";
        "调度 implementer 子代理 (./implementer-prompt.md)" [shape=box];
        "Implementer 子代理有问题？" [shape=diamond];
        "回答问题、提供上下文" [shape=box];
        "Implementer 子代理实现、stage 待评审、自审" [shape=box];
        "调度 spec 审阅者子代理 (./spec-reviewer-prompt.md)" [shape=box];
        "Spec 审阅者子代理确认代码与 spec 一致？" [shape=diamond];
        "Implementer 子代理修复 spec 缺口" [shape=box];
        "在 TodoWrite 中标记任务完成" [shape=box];
    }

    "读计划、抽出所有任务的完整文本、记下上下文、创建 TodoWrite" [shape=box];
    "还有任务？" [shape=diamond];
    "对整个实现调度最终 code reviewer 子代理（用 opus）" [shape=box];
    "实施完成" [shape=box style=filled fillcolor=lightgreen];

    "读计划、抽出所有任务的完整文本、记下上下文、创建 TodoWrite" -> "调度 implementer 子代理 (./implementer-prompt.md)";
    "调度 implementer 子代理 (./implementer-prompt.md)" -> "Implementer 子代理有问题？";
    "Implementer 子代理有问题？" -> "回答问题、提供上下文" [label="是"];
    "回答问题、提供上下文" -> "调度 implementer 子代理 (./implementer-prompt.md)";
    "Implementer 子代理有问题？" -> "Implementer 子代理实现、stage 待评审、自审" [label="否"];
    "Implementer 子代理实现、stage 待评审、自审" -> "调度 spec 审阅者子代理 (./spec-reviewer-prompt.md)";
    "调度 spec 审阅者子代理 (./spec-reviewer-prompt.md)" -> "Spec 审阅者子代理确认代码与 spec 一致？";
    "Spec 审阅者子代理确认代码与 spec 一致？" -> "Implementer 子代理修复 spec 缺口" [label="否"];
    "Implementer 子代理修复 spec 缺口" -> "调度 spec 审阅者子代理 (./spec-reviewer-prompt.md)" [label="复审"];
    "Spec 审阅者子代理确认代码与 spec 一致？" -> "在 TodoWrite 中标记任务完成" [label="是"];
    "在 TodoWrite 中标记任务完成" -> "还有任务？";
    "还有任务？" -> "调度 implementer 子代理 (./implementer-prompt.md)" [label="是"];
    "还有任务？" -> "对整个实现调度最终 code reviewer 子代理（用 opus）" [label="否"];
    "对整个实现调度最终 code reviewer 子代理（用 opus）" -> "实施完成";
}
```

## 模型选择

用能胜任的最弱模型来节省成本、提高速度。

**机械式实现任务**（独立函数、清晰 spec、1-2 个文件）：用快、便宜的模型。当计划写得很细时，大多数实现任务是机械的。

**集成与判断任务**（多文件协调、模式匹配、调试）：用标准模型。

**架构、设计和评审任务**：用可用的最强模型。

**任务复杂度信号：**
- 涉及 1-2 个文件且 spec 完整 → 便宜模型
- 涉及多个文件且有集成顾虑 → 标准模型
- 需要设计判断或对代码库的广泛理解 → 最强模型

## 处理 Implementer 状态

Implementer 子代理会汇报四种状态之一。各自妥善处理：

**DONE：** 进入 spec 合规性评审。

**DONE_WITH_CONCERNS：** Implementer 完成了工作但提出了顾虑。继续前先读这些顾虑。如果顾虑涉及正确性或范围，先解决再去评审。如果只是观察（比如"这个文件越来越大"），记下并继续到评审。

**NEEDS_CONTEXT：** Implementer 需要未被提供的信息。提供缺失的上下文并重新调度。

**BLOCKED：** Implementer 无法完成任务。评估阻塞原因：
1. 如果是上下文问题，提供更多上下文，用同一模型重新调度
2. 如果任务需要更强的推理，换更强模型重新调度
3. 如果任务太大，拆成更小的片段
4. 如果计划本身错了，升级给用户

**永远不要**忽略上报，或不做改变就让同一模型再试一遍。Implementer 说卡住了，就一定要改变点什么。

## Prompt 模板

- `./implementer-prompt.md` - 调度 implementer 子代理
- `./spec-reviewer-prompt.md` - 调度 spec 合规审阅者子代理
- `./code-reviewer.md` - 所有任务完成后做一次最终代码评审（对整个实现，用最强模型 opus 调度评审子代理；若发现 Critical/Important 问题，交由 implementer 子代理修复）

## 示例工作流

```
你: 我正在使用 Subagent-Driven Development 执行此计划。

[一次性读取计划文件: docs/superpowers/plans/feature-plan.md]
[抽出全部 5 个任务的完整文本和上下文]
[用所有任务创建 TodoWrite]

Task 1: Hook 安装脚本

[获取 Task 1 的文本和上下文（已抽出）]
[用完整任务文本 + 上下文调度 implementation 子代理]

Implementer: "开始前——hook 应该装在用户级还是系统级？"

你: "用户级（~/.config/superpowers/hooks/）"

Implementer: "明白。现在开始实现……"
[稍后] Implementer:
  - 实现了 install-hook 命令
  - 静态检查通过（shellcheck / 项目 lint）
  - 自审：发现漏了 --force 标志，已加上
  - 已暂存待评审（未提交）

[调度 spec 合规审阅者]
Spec reviewer: ✅ Spec 合规——所有需求满足，没多余的

[标记 Task 1 完成]

Task 2: 恢复模式

[获取 Task 2 的文本和上下文（已抽出）]
[用完整任务文本 + 上下文调度 implementation 子代理]

Implementer: [无问题，开始]
Implementer:
  - 加了 verify/repair 模式
  - 静态检查通过；本任务明确要求测试覆盖，加了 8 条单元测试，全部通过
  - 自审：都没问题
  - 已暂存待评审（未提交）

[调度 spec 合规审阅者]
Spec reviewer: ❌ 问题：
  - 缺失：进度上报（spec 说"每 100 项上报一次"）
  - 多余：加了 --json 标志（未请求）

[Implementer 修问题]
Implementer: 删了 --json 标志，加了进度上报

[Spec reviewer 再次评审]
Spec reviewer: ✅ 现已合规

[标记 Task 2 完成]

...

[所有任务完成后，用 ./code-reviewer.md 模板对整个实现调度一个最终 code reviewer 子代理（用 opus）]
Final reviewer: 优点：结构清晰、错误处理到位、测试覆盖全面。仅一处 Minor（缺少进度计数）。Ready to merge: Yes。

完成！
```

## 优势

**vs. 手动执行：**
- 子代理精确遵循计划步骤
- 每个任务都是全新上下文（不会混淆）
- 并行安全（子代理互不干扰）
- 子代理可以提问（开始前和工作中）

**vs. Executing Plans：**
- 同一会话（无交接）
- 持续推进（不等待）
- 自动评审检查点

**效率提升：**
- 无文件读取开销（controller 提供完整文本）
- Controller 精确策划所需的上下文
- 子代理一上来就拿到完整信息
- 问题在工作开始前就浮出（不是事后）

**质量门：**
- 自审在交接前发现问题
- 每任务 spec 合规评审，评审循环确保修复确实生效
- Spec 合规阻止过建/欠建
- 收口一次最终代码评审（用 opus）对整个实现做功能性审查：计划对齐、代码质量、架构、测试、生产就绪

**成本：**
- 子代理调用更多（每任务 implementer + 1 个 spec reviewer，最后 1 次最终代码评审）
- Controller 准备工作更多（前期抽出所有任务）
- 评审循环增加迭代
- 但能更早发现问题（比后期调试便宜）

## 红线

**绝不：**
- 未经用户明确同意，不要在 main/master 分支上开始实施
- 跳过每任务的 spec 合规评审，或跳过收口的最终代码评审
- 带着未修复的问题继续
- 并行调度多个 implementation 子代理（会冲突）
- 让子代理去读计划文件（要提供完整文本）
- 跳过场景铺垫（子代理需要理解任务的位置）
- 忽略子代理的问题（先答完再让它继续）
- "差不多就行"地接受 spec 合规（spec reviewer 发现问题 = 没做完）
- 跳过评审循环（reviewer 发现问题 = implementer 修 = 再评审）
- 让 implementer 的自审替代真正的评审（两者都需要）
- spec 评审有未关闭的问题时就推进下一任务

**如果子代理提问：**
- 清晰、完整地回答
- 必要时提供额外上下文
- 不要催它进入实现

**如果 reviewer 发现问题：**
- 由（同一）Implementer 子代理修复
- Reviewer 再次评审
- 重复直到 approved
- 不要跳过复审

**如果子代理任务失败：**
- 调度修复子代理并给出具体指令
- 不要手动修（会污染上下文）

## 集成

**相关 skills：**
- **writing-plans** - 创建本 skill 要执行的计划
- **executing-plans** - 替代方案：同会话批量执行（无每任务评审）

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [MySwallow](https://github.com/MySwallow)
- **Source:** [MySwallow/superpowers-lite](https://github.com/MySwallow/superpowers-lite)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-myswallow-superpowers-lite-subagent-driven-development
- Seller: https://agentstack.voostack.com/s/myswallow
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.