核心用法
spec-first-dev 是一套严格遵循"规格优先、编码其次"原则的强制流程。当用户启动任何非琐碎开发任务时（定义：涉及 2 个以上文件或耗时超过 15 分钟），该技能自动介入，强制要求先产出完整的 SPEC.md 文档，经用户明确批准后方能进入实现阶段。
执行流程分为五步：
1. 澄清意图 — 解析项目目标、使用者画像与关键约束（技术栈、预算、时间），必要时提出唯一澄清问题
2. 探索现有代码库 — 通过 Glob/Grep 扫描相关文件，识别可复用组件、潜在冲突点
3. 生成 SPEC.md — 输出涵盖数据模型、用户流/API 契约、文件结构、边界情况与异常处理、明确排除项、待决策问题的完整规格文档
4. 呈现与关卡 — 向用户展示规格并显式暂停，等待明确批准（回复 "go" 或修改指令），严禁未经批准即编写代码
5. 按规格实现 — 逐节执行、逐项勾选、实时标记偏差，新发现的边界情况须补入规格并注明
显著优点
- 从根本上消除"构建错误产品"：80% 的 AI 辅助开发失败源于需求模糊即编码，该技能通过强制关卡机制阻断此路径
- 可审计的决策链条：SPEC.md 成为代码审查附件、团队交接简报、版本追溯依据
- 边界情况显性化：专设章节强制枚举空状态、并发竞争、失效场景等，减少生产环境意外
- 灵活适配：既支持主动调用
/spec-first-dev [描述]，也可通过"build me""create a"等短语自动触发
潜在缺点与局限
- 轻量任务 overhead：对于 15 分钟内完成的原子任务，完整规格流程可能显得冗余
- 单点瓶颈：用户批准环节若响应延迟，会阻断开发进度
- 规格质量依赖探索深度：Step 2 的代码库扫描若遗漏关键上下文，可能导致规格与现有架构冲突
- 未覆盖安全专项：规格模板未内置安全需求（认证授权、输入校验、敏感数据处理）的强制检查清单
适合人群
- 独立开发者启动 MVP 或功能迭代时寻求结构化约束
- 团队场景下需要可交付的规格文档作为沟通媒介
- AI 辅助编程用户希望降低"理解偏差→返工"的摩擦成本
常规风险
- 批准即承诺偏差：用户快速浏览后批准，实际开发中发现规格疏漏，可能引发范围蔓延或技术债务
- 隐式偏差累积：虽有"标记偏差"要求，但实际执行中可能因对话流畅性而淡化处理
- 工具权限：依赖 Read/Write/Bash/Glob，在受限环境（如只读文件系统）中 Step 2 的探索能力受限