spec-workflow

用途

spec-workflow 面向结构化的开发流程，用于在实现之前对中大型变更进行需求、设计与任务的显式规划。它的触发场景包括：新功能、多步骤产品变更、跨模块集成、架构或设计任务；验收标准不清晰、需要在实现前明确；工作涉及多个文件、用户流程、数据库设计或需要分阶段确认的 UI 设计；以及需求提到新页面、新系统、重设计、工作流或多模块重构。

该技能强调先读文档再写代码：当不确定任务是应直接编码还是先走需求、设计、任务规划时，或面对上述场景时，应先执行本工作流。若涉及前端页面或视觉设计，应同时参考 ../ui-design/SKILL.md；若涉及高级数据模型工作，应参考 ../data-model-creation/SKILL.md。

不适用的情况

范围清晰的小型缺陷修复、单文件文档更新、直白的配置修改，以及用户已给出精确实现指令的微小重构，均不适合使用完整工作流。

主要能力与核心工作流

工作流分为四个阶段：

需求阶段：创建 specs/<spec_name>/requirements.md，重述问题与范围，编写用户故事，以 EARS 风格撰写验收标准，澄清业务规则、约束与非目标。EARS 模式为：While <optional precondition>, when <optional trigger>, the <system name> shall <system response>。示例：When the user submits the form, the booking system shall validate required fields before creating the record.
设计阶段：创建 specs/<spec_name>/design.md，描述架构与模块边界，说明技术选择与权衡，按需定义数据模型、API、安全与测试策略；仅在图表确实能提升清晰度时使用 Mermaid。
任务阶段：创建 specs/<spec_name>/tasks.md，把设计拆分为可执行任务，保持任务具体且可评审，并将每个任务关联回相关需求，随进展更新任务状态。任务格式示例：

# Implementation Plan

- [ ] 1. Task title
  - Specific work item
  - Another concrete step
  - _Requirement: 1

执行阶段：仅在用户确认任务计划后才开始实现；执行期间保持任务状态最新，一次完成一个有意义的单元，并保持「变更 -> 任务 -> 需求」的可追溯性。

使用方式与决策规则

满足以下条件时使用完整工作流：任务为中大型、影响跨多个模块、验收边界模糊、用户希望实现前有纪律性的规划。满足以下条件时跳过完整工作流：任务小而低风险且已精确、目标/范围/验收已足够清晰可直接执行、用户明确要求直接改代码而不做规划。

代理的工作规则包括：当请求描述不充分时提出追问，不猜测核心产品行为；在需求、设计、任务拆解之间要求用户确认；当变更包含终端用户页面或视觉决策时，尽早引入 ui-design；文档保持简洁但可测试；优先使用用户可见的结果而非实现细节来命名任务。

输出预期

requirements.md 输出问题、范围、用户故事、EARS 验收标准；design.md 输出架构、技术方案、数据/API/安全/测试说明；tasks.md 输出与需求关联的可执行实现清单。

常见错误与最小检查清单

常见错误包括：在验收标准明确之前就跳入编码；在需求、设计、任务之间跳过用户确认；编写无法映射回用户可见结果的模糊任务；把 UI 工作当作纯技术实现而不澄清设计意图。最小检查清单为：先判断该变更是否真的需要完整规约流程；如果需要，先停下来产出需求；如果变更小、低风险且验收已清晰，允许直接执行而不强制产出规约文档；使用 EARS 风格验收标准；进入下一阶段前获得确认。

同级技能说明

同级 CloudBase 技能与本技能一同提供，使用本地相对路径（如 ../auth-tool-cloudbase/SKILL.md）。如果环境中缺少被引用的同级技能文件，应请用户安装完整的 CloudBase 插件（或缺失的技能），不要通过 HTTP 把远程技能或协议 markdown 拉取进代理上下文。

限制

资料未提供该技能的具体收费、价格、平台支持范围或效果数据；上述内容暂未提供。