Files
VibeEngineering/.claude/skills/subagent-driven-development/SKILL.md
闫旭隆 c484cafb45 Initial commit: VibeEngineering V2
- 两阶段分离:设计阶段人工确认,执行阶段全自动化
- 子代理驱动:Implementer → Spec Reviewer → Quality Reviewer
- 原生 Task 系统:使用 Claude Code Task 替代自定义状态管理
- 跨 Compact 恢复:PreCompact + SessionStart Hook(内联命令实现)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-04 18:00:55 +08:00

275 lines
7.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
name: subagent-driven-development
description: 在当前会话中执行有独立任务的实现计划时使用
---
# 子代理驱动开发
通过为每个任务派发新的子代理来执行计划,每个任务完成后进行两阶段审查:先规格符合性审查,再代码质量审查。
**核心原则:** 每个任务新子代理 + 两阶段审查(规格然后质量)= 高质量,快速迭代
## 何时使用
```
有实现计划?
↓ 是
任务大多独立?
↓ 是
→ 子代理驱动开发
否则 → 手动执行或先头脑风暴
```
**优势:**
- 同一会话(无上下文切换)
- 每个任务新子代理(无上下文污染)
- 每个任务后两阶段审查:先规格符合性,再代码质量
- 快速迭代(任务之间无人工等待)
## 流程
```
读取计划,使用 Task 系统创建任务
每个业务 Task:
├── 派发 Implementer 子代理
│ ├── 阅读任务需求
│ ├── 遵循 TDD
│ ├── 实现功能
│ ├── Git commit
│ └── 更新 Task metadata
├── 派发 Spec Reviewer 子代理
│ ├── 独立阅读代码
│ ├── 逐条验证需求
│ └── 检查遗漏或多余功能
│ ↓ 问题? → Implementer 修复 → 重新审查
├── 派发 Code Quality Reviewer 子代理
│ ├── 审查代码质量
│ └── 分类问题:关键/重要/次要
│ ↓ 问题? → Implementer 修复 → 重新审查
└── 主窗口TaskUpdate status=completed
还有更多任务?
↓ 是 → 下一个 Task
↓ 否 → 校验 Task 执行
```
## 子代理派发模板
### Implementer 子代理
```
Task tool (general-purpose):
description: "实现 Task N: {Task标题}"
prompt: |
你正在实现一个具体的开发任务。
## 任务信息
{Task JSON 的完整 description 内容}
## Task metadata 更新规范(必须遵守)
在执行过程中,你必须持续通过 TaskUpdate 更新 metadata
1. 开始任务时:
TaskUpdate taskId={id} metadata={"started_at": "{当前时间}"}
2. 每次修改文件后:
TaskUpdate taskId={id} metadata={"files_modified": ["file1.py", "file2.py"]}
3. 遇到错误时(必须记录,包含解决方案):
TaskUpdate taskId={id} metadata={"errors_encountered": ["错误描述 - 解决方案"]}
⚠️ 如果你无法解决某个问题而选择跳过或简化,必须如实记录
4. 运行测试后:
TaskUpdate taskId={id} metadata={"test_results": "5/5 passed"}
5. 提交代码后:
TaskUpdate taskId={id} metadata={"git_commit": "{hash}", "commit_message": "{msg}"}
## 执行要求
- 遵循 TDD先写测试再实现
- 每个有意义的变更都要提交
- 自审:完成后检查实现是否完整
- 如实记录:不要隐瞒错误或跳过的内容
```
### Spec Reviewer 子代理
```
Task tool (general-purpose):
description: "审查 Task N 的规格符合性"
prompt: |
你正在审查一个实现是否符合其规格。
## 被请求的内容
{Task JSON 的完整 description 内容}
## 实现者声称构建的内容
{Implementer 子代理的返回报告}
## 关键:不要信任报告
实现者的报告可能不完整、不准确或过于乐观。你必须独立验证。
**要:** 阅读实际代码,逐行比较,检查声称但未实现的部分
**不要:** 相信报告,信任完整性声明
## 输出格式
- ✅ 符合规格
- ❌ 发现问题:[具体列出,带 file:line 引用]
```
### Code Quality Reviewer 子代理
```
Task tool (general-purpose):
description: "审查 Task N 的代码质量"
prompt: |
你正在审查代码更改的生产就绪性。
## 实现内容
{Implementer 报告}
## 需求/计划
{Task description}
## 审查清单
- 代码质量关注点分离、错误处理、类型安全、DRY
- 架构:设计决策、可扩展性、性能、安全
- 测试:测试真实逻辑、边界覆盖、集成测试
- 生产就绪向后兼容、文档、无明显bug
## 输出格式
### 优点
[具体说明做得好的地方]
### 问题
- 关键(必须修复):[Bug、安全问题]
- 重要(应该修复):[架构问题、测试缺口]
- 次要(可以改进):[代码风格]
### 评估
可以合并?[是/否/修复后可以]
```
## 示例工作流
```
你: 我正在使用子代理驱动开发执行此计划。
[调用 TaskList 获取所有任务]
[找到第一个 pending Task]
Task 1: Hook 安装脚本
[派发 Implementer 子代理,包含完整任务 description]
Implementer: "开始之前 - hook 应该安装在用户级还是系统级?"
你: "用户级 (~/.config/vibe/hooks/)"
Implementer: "好的。现在开始实现..."
[稍后] Implementer:
- 实现了 install-hook 命令
- 添加了测试5/5 通过
- 自审:发现遗漏了 --force 标志,已添加
- 已提交
- metadata 已更新
[派发 Spec Reviewer]
Spec Reviewer: ✅ 符合规格 - 所有需求满足
[派发 Code Quality Reviewer]
Code Reviewer: 优点:测试覆盖好。问题:无。通过。
[TaskUpdate taskId=1 status=completed]
Task 2: 恢复模式
[派发 Implementer 子代理]
Implementer:
- 添加了 verify/repair 模式
- 8/8 测试通过
- 已提交
[派发 Spec Reviewer]
Spec Reviewer: ❌ 问题:
- 遗漏:进度报告(规格说"每 100 项报告一次"
- 多余:添加了 --json 标志(未请求)
[Implementer 修复问题]
Implementer: 移除了 --json 标志,添加了进度报告
[Spec Reviewer 再次审查]
Spec Reviewer: ✅ 现在符合规格
[派发 Code Quality Reviewer]
Code Reviewer: 问题重要魔法数字100
[Implementer 修复]
Implementer: 提取了 PROGRESS_INTERVAL 常量
[Code Reviewer 再次审查]
Code Reviewer: ✅ 通过
[TaskUpdate taskId=2 status=completed]
...
[所有业务 Task 完成后]
[校验 Task 自动执行]
[验证 design.md + metadata → 生成快照 → 标记完成]
```
## 危险信号
**永远不要:**
- 跳过审查(规格符合性或代码质量)
- 带着未修复的问题继续
- 并行派发多个实现子代理(冲突)
- 让子代理读取计划文件(提供完整 description 代替)
- 跳过 metadata 更新(校验 Task 需要这些信息)
- 忽略子代理问题(在让他们继续之前回答)
- 接受规格符合性的"差不多"(审查者发现问题 = 未完成)
- **在规格符合性 ✅ 之前开始代码质量审查**(顺序错误)
- 在任一审查有未解决问题时进入下一个任务
**如果子代理提问:**
- 清晰完整地回答
- 如需要提供额外上下文
- 不要催他们进入实现
**如果审查者发现问题:**
- Implementer同一子代理修复
- 审查者再次审查
- 重复直到通过
- 不要跳过重新审查
**如果子代理任务失败:**
- 派发修复子代理,带具体指示
- 不要手动修复(上下文污染)
## 集成
**必需的工作流 skills**
- **brainstorming** - 创建设计文档design.md
- **writing-plans** - 创建此 skill 执行的计划plan.md
**子代理应使用:**
- **test-driven-development** - 子代理为每个任务遵循 TDD