Workflow skills定义如下：
---
name: workflow
description: |
当用户提出新功能需求、开发任务或需要按照规范流程进行软件开发时使用。涵盖从需求探索、规范提案、审视审查、TDD 实现到验证审查和归档收尾的完整开发周期。每个阶段有明确门控，未满足完成标准不得进入下一阶段。
---
# 自动化开发工作流
将 OpenSpec + Superpowers 编排为一条完整流水线：探索想法 → 规范提案 → 审视审查 → TDD 实现 → 验证审查 → 归档收尾。
## 使用时机
- 用户提出新功能、修复或变更需求
- 用户说"我想构建 / 添加 / 修复 / 重构 X"
- 用户要求按照规范流程进行开发
- 从零开始的非琐碎任务（3+ 步骤或涉及架构决策）
**不适用于：** 纯提问、仅探索的会话。
## 流程用户想法
↓
复杂度判断
├── 简单任务 → 短路执行 → 验证 → 完成
↓
阶段 0：需求探索 → openspec-explore
→ 🚪 门控：意图清晰 + 用户同意进入提案
↓
阶段 1：规范提案 → openspec-propose
→ 🚪 门控：所有产出物完成 + 用户批准
↓
阶段 2：审视审查 → brainstorming + writing-plans
→ 🚪 门控：spec review 通过 + 用户确认计划
↓
阶段 3：TDD 实现 → subagent-driven-development
→ 🚪 门控：所有任务 x + 测试通过
↓
阶段 4：验证审查 → verification + code-review
→ 🚪 门控：新鲜验证通过 + 审查完成
↓
阶段 5：归档收尾 → archive + finishing-branch
→ 🚪 门控：变更已归档
## 阶段详情
### 阶段 0：探索
**技能：** `openspec-explore`
自由思考，澄清意图。不写代码，不实现功能。见解清晰后，建议进入提案阶段。
**完成标准：**
- [ ] 用户意图已澄清（技术栈、范围、约束已确认）
- [ ] 用户同意进入提案阶段
### 阶段 1：提案
**技能：** `openspec-propose`
生成所有产出物（proposal、specs、design、tasks）。暂停等待用户审阅。
**完成标准：**
- [ ] proposal 包含"非目标"
- [ ] 每个需求有场景（`#### 场景:名称` 格式）
- [ ] design 列出替代方案和选择理由
- [ ] tasks 使用 `- [ ]` 格式
- [ ] 用户已审阅并批准产出物
### 阶段 2：审视审查
**技能：** `superpowers:brainstorming` → `superpowers:writing-plans`
**Part A：Spec 质量审查**（在写代码之前发现问题）
1. 逐条审视每个 spec：遗漏、矛盾、模糊、缺失场景
2. 发现问题立即修复 spec
3. 检查 design 决策是否完整
**Part B：实现计划**
1. 使用 `writing-plans` 创建详细计划
2. 每个任务包含：文件路径、代码、测试、验证命令
3. 呈现计划给用户确认
**完成标准：**
- [ ] 所有 spec 经过审查，无遗漏/矛盾/模糊
- [ ] 实现计划已创建
- [ ] 用户已确认计划
### 阶段 3：TDD 实现
**技能：** `superpowers:subagent-driven-development` + `superpowers:test-driven-development`
**子代理使用规则：**
| 任务特征 | 执行方式 | 说明 |
|----------|---------|------|
| 独立任务（无文件/逻辑冲突） | **子代理执行**（必须） | 隔离上下文，可并行派发 |
| 紧密耦合任务（共享文件/状态） | 顺序子代理或合并为一个子代理 | 避免冲突 |
| 端到端验证、需实时调整 | 内联执行 | 需要观察结果调整方向 |
| 单文件琐碎修复 | 内联执行 | 子代理开销 > 任务本身 |
**子代理必须遵循 TDD：**
派发子代理时，prompt 中明确要求：
1. **Red**：先写失败测试，运行确认失败
2. **Green**：写最少代码让测试通过，运行确认通过
3. **Refactor**：优化代码，重新运行测试
4. 标记任务 `[x]` 并 commit
**执行流程：**
1. 读取所有上下文文件（spec、design、plan）
2. 判断任务独立性，分组派发子代理
3. 每个子代理 prompt 包含：完整任务描述 + TDD 要求 + 验证命令
4. 子代理报告 DONE 后，由主控制器验证
**约束：**
- 实现前先读 spec
- 不偏离 tasks.md 范围
- 遇阻暂停报告，不猜测
- 独立任务必须用子代理（保护主上下文）
**完成标准：**
- [ ] 所有任务标记 `[x]`
- [ ] 所有测试通过（新鲜运行）
### 阶段 4：验证审查
**技能：** `superpowers:verification-before-completion` → `superpowers:requesting-code-review`
1. **新鲜验证**：运行全部测试和构建（必须本次会话运行，不信任历史结果）
2. 有失败？→ `systematic-debugging`，修复后重新验证
3. **代码审查**：spec 覆盖度、代码质量、安全问题
**完成标准：**
- [ ] 测试新鲜运行通过
- [ ] 构建成功
- [ ] 代码审查无 Critical/Important 未解决问题
**铁律**：不在有新鲜验证证据前声称完成
### 阶段 5：归档收尾
**技能：** `openspec-archive-change` + `superpowers:finishing-a-development-branch`
同步规范，归档变更，收尾分支。
**完成标准：**
- [ ] 增量规范已同步到主 specs
- [ ] 变更已归档
- [ ] Git 已提交
## 速查表
| 阶段 | OpenSpec | Superpowers | 门控 |
|------|----------|-------------|------|
| 0 探索 | `openspec-explore` | --- | 意图清晰 + 用户同意 |
| 1 提案 | `openspec-propose` | --- | 产出物完成 + 用户批准 |
| 2 审视 | --- | `brainstorming` → `writing-plans` | spec review 通过 + 用户确认计划 |
| 3 实现 | `openspec-apply-change` | `subagent-driven-development` + `test-driven-development` | 所有任务 `[x]` + 测试通过 |
| 4 验证 | --- | `verification` → `code-review` | 新鲜验证通过 + 审查完成 |
| 5 归档 | `openspec-archive-change` | `finishing-a-development-branch` | 变更已归档 |
## 常见错误
| 错误 | 修正 |
|------|------|
| 跳过探索 → spec 模糊 | 非琐碎变更必须先探索 |
| 不做计划就实现 | 阶段 2 在阶段 3 之前是强制的 |
| 先写代码再写测试 | 必须用 TDD --- 先 Red 再 Green |
| 没验证就标记完成 | 必须新鲜运行验证 |
| 超出 tasks.md 范围 | 新工作 → 新任务或新变更 |
| 遇阻时猜测而非提问 | 停下来问------不要编造方案 |
| 跳过用户审阅关口 | 每个阶段结束需要用户明确确认 |
| 实现后才做 spec review | spec review 应在阶段 2 完成 |
## 红旗 --- 停下来纠正
- 先写代码后写测试
- "我之后再补测试"
- 没运行验证就标记任务完成
- 实现了 tasks.md 之外的东西
- 因为"简单"而跳过某个阶段
- 遇阻时继续而非提问
- 信任历史测试结果而非新鲜运行
**遇到以上情况：暂停，纠正方向，再继续。**第二步在项目中新建如下目录：
mkdir .claude/skills/workflow
然后 vi skill.md 将上面内容复制进去保存
第三步
直接用/workflow调用工作流，输入需求就可以了，整个工作流就调用了。
