用途：在需求方向获用户批准后，把 refine 产出转化为结构化、可验证的正式 spec 文档，再进入设计或计划阶段。
主要能力：写 spec 前先列出隐藏假设并要求用户纠正；spec 覆盖九个核心区域——Objective、Artifact Type（默认 software）、Goal Alignment（含 Done When 与 Stop Conditions）、Commands/Tools、Project Structure、Style/Quality Bar、Verification Strategy、Documentation Impact、Boundaries（Always/Ask first/Never）；把模糊需求转为可测验收条件，例如将“让仪表盘更快”改为 LCP<2.5s、初始加载<500ms、CLS<0.1；区分 spec 级 Success Criteria 与 goal 级 Done When 并要求一致；规定失败处理（用户拒绝则回 refine，缺 Success Criteria 强制补充，project_truth_changed 为 yes 却无受影响文档路径则阻塞）。
使用方式：refine 完成且方向获批后进入；输出到 docs/features/YYYYMMDD-<name>/01-spec.md。核心命令示例：npm run build、npm test -- --coverage、npm run lint --fix、npm run dev。spec 经用户审查批准后，优先调用 design-workflow-design；纯后端、脚本或迁移可跳到 build-workflow-plan。可选加载 CANON.md，有架构决策时加载 build-cognitive-decision-record/SKILL.md。
适用场景：需要正式规范的功能开发；不适用于单行修复、打字错误、需求明确且自包含的变更，以及纯配置变更、依赖升级等无需设计决策的改动。
限制：具体价格、收费与平台信息暂未提供。