核心能力
Spec Workflow Guide 是一套结构化的软件开发治理框架，专为中型至大型功能开发、跨模块集成和架构设计任务而设计。它通过强制性的四阶段流程（Requirements → Design → Tasks → Execution），解决"边写边想"导致的返工、验收争议和技术债务问题。
显著优点
1. 质量门禁机制
采用 EARS（Easy Approach to Requirements Syntax）语法编写验收标准，将模糊的"用户体验好"转化为可测试的"When the user submits the form, the booking system shall validate required fields"。这种强制精确化显著降低交付争议。
2. 阶段确认制
明确要求用户在进入下一阶段前确认当前产出，避免"我以为你要的是这个"型错误。特别适合外包场景或产品经理与开发者认知偏差较大的团队。
3. 可追溯性设计
每个任务必须关联回具体需求条目（_Requirement: 1），确保代码变更与业务目标的关系可审计，这对合规性要求高的金融、医疗行业尤为关键。
4. 模块化扩展
与 UI Design、Data Model Creation 等子技能形成引用关系，可按需组合而非强制全量使用，兼顾规范性与灵活性。
潜在局限
- overhead 敏感：对于 2 小时能完成的明确任务，四阶段文档产出可能耗时超过编码本身
- 学习曲线：EARS 语法对非技术背景的 PO 不够友好，需要培训投入
- 流程惯性：一旦形成文档习惯，团队可能机械执行而忽视"是否真需要此流程"的判断
适合人群
- 中型以上团队（5+ 开发者）缺乏统一交付标准
- 微服务/多仓库架构下频繁出现接口不匹配
- 客户交付场景需要书面验收依据
- 技术负责人希望从"救火"转向"防火"
常规风险
| 风险场景 | 缓解建议 |
|---------|---------|
跳过验收标准直接编码 | 启用技能时强制检查 EARS 条目存在性 |
| 任务粒度失控（过大或碎片化） | 要求每个任务能在 1-2 天内完成并有明确 reviewable 产出 |
| 设计文档与实际代码脱节 | 执行阶段强制更新任务状态，建立代码提交 → task → requirement 的链接 |
| 过度设计 | Design 阶段限定"Use Mermaid only when materially improves clarity" |
该技能本质是开发者与请求者之间的认知对齐工具，价值随项目复杂度递增，简单场景建议直接跳过。