/spec Skill - 规格定义工作流程
规格驱动开发（SDD）的上游工程负责的Skill。 从自然语言需求出发，逐步生成结构化的规格书（EPIC/Story/Subtask）。
发动条件
以下关键词自动发动：
- 「specを作成して」「仕様を策定して」
- 「[機能名]のspecを書いて」
- 「新機能の仕様を定義して」
- 「要件を整理して」
基本原则
- 阶段性对话: Requirements → Design → Tasks 的3阶段
- EARS语法: 生成无歧义的验收标准
- 用户确认: 各阶段确认「进行下一步」后生成文件
- 3层级输出: 适当分割EPIC/Story/Subtask文件
工作流程
第1阶段：需求发现（Requirements Discovery）
┌─────────────────────────────────────────────────┐
│ 1. 需求听取 │
│ - 接收用户自然语言输入 │
│ - 如有不明之处则提问 │
│ │
│ 2. 用户故事生成 │
│ - 明确化角色、目的、价值、理由 │
│ - 明确化隐含需求 │
│ │
│ 3. EARS语法AC生成 │
│ - WHEN/GIVEN/THEN形式结构化 │
│ - 考虑边缘情况 │
│ - 补充安全/性能需求 │
│ │
│ 4. 用户确认 │
│ 「这个需求可以进行吗？」 │
│ - 「进行下一步」→ 第2阶段 │
│ - 「修改」→ 调整内容 │
└─────────────────────────────────────────────────┘
第2阶段：设计探索（Design Exploration）
┌─────────────────────────────────────────────────┐
│ 1. 现有代码库分析 │
│ - 探索相关现有代码 │
│ - 确认使用的技术栈 │
│ - 确认与现有模式的一致性 │
│ │
│ 2. 技术设计生成 │
│ - 数据流图（Mermaid） │
│ - 接口定义（TypeScript） │
│ - API设计（如有必要） │
│ │
│ 3. 架构决策 │
│ - 如有多个方法则提出选择项 │
│ - 解释权衡 │
│ │
│ 4. 用户确认 │
│ 「这个设计可以进行吗？」 │
│ - 「进行下一步」→ 第3阶段 │
│ - 「修改」→ 调整设计 │
└─────────────────────────────────────────────────┘
第3阶段：任务分解（Task Breakdown）
┌─────────────────────────────────────────────────┐
│ 1. EPIC/Story/Subtask分割 │
│ - 适当粒度的Subtask分割 │
│ - 1 Subtask = 1功能 │
│ - 整理依赖关系 │
│ │
│ 2. 实施顺序优化 │
│ - 根据依赖关系排序 │
│ - 先放置基础功能 │
│ │
│ 3. 文件生成预览 │
│ - 显示生成文件列表 │
│ - 解释每个文件概要 │
│ │
│ 4. 用户确认 │
│ 「这个任务分解可以进行吗？」 │
│ - 「进行下一步」→ 文件生成 │
│ - 「修改」→ 调整分割 │
└─────────────────────────────────────────────────┘
文件生成
┌─────────────────────────────────────────────────┐
│ 生成文件: │
│ │
│ specs/{epic-id}/{epic-id}.md │
│ ├── 用户故事 │
│ ├── EPIC级别AC │
│ └── 相关Story链接 │
│ │
│ specs/{epic-id}/{story-id}/{story-id}.md │
│ ├── 用户故事 │
│ ├── Story级别AC │
│ └── 相关Subtask链接 │
│ │
│ specs/{epic-id}/{story-id}/{subtask-id}.md │
│ ├── 用户故事 │
│ ├── EARS语法AC │
│ ├── 设计部分（如适用） │
│ └── 测试用例模板 │
│ │
│ 列表文件: │
│ specs/epic-list.md │
│ specs/{epic-id}/story-list.md │
│ specs/{epic-id}/{story-id}/subtask-list.md │
└─────────────────────────────────────────────────┘
EARS语法模板
事件驱动型
- [ ] WHEN [触发・情况]
GIVEN [前提条件]
THEN [预期动作]
AND [附加动作]
状态依赖型
- [ ] WHILE [状态・过程]
THE SYSTEM SHALL [必须动作]
AND [相关动作]
条件型
- [ ] WHERE [功能・组件]
IF [条件・状态]
THE SYSTEM SHALL [对应动作]
对话控制命令
| 命令 | 动作 |
|---|---|
| 「进行下一步」 | 完成当前阶段，进入下一阶段 |
| 「修改」 | 在当前阶段内调整内容 |
| 「重新开始」 | 从当前阶段重新开始 |
| 「详细说明」 | 提供更详细的说明或选项 |
| 「跳过」 | 跳过当前阶段（不推荐） |
输出示例
输入
「用户认证功能的spec创建。包括OAuth对应、多因素认证」
第1阶段输出（需求）
## 用户故事
**角色**: 终端用户 / 管理员
**目的**: 安全地访问系统
**价值**: 在保护个人信息的同时确保便利性
**理由**: 防止未授权访问，同时提高登录体验
## 验收标准（EARS语法）
### 基本认证
- [ ] WHEN 用户尝试登录
GIVEN 输入有效的电子邮件地址和密码
THEN 系统创建会话
AND 重定向到仪表板
- [ ] WHEN 用户尝试登录
GIVEN 输入无效的认证信息
THEN 系统显示错误消息
AND 计数尝试次数
### OAuth认证
- [ ] WHEN 用户选择OAuth提供商登录
GIVEN 使用Google/GitHub账户认证
THEN 系统连接账户
AND 如果是首次则创建用户配置文件
### 多因素认证
- [ ] WHEN MFA启用用户完成密码认证
GIVEN 输入正确的密码
THEN 系统显示MFA代码输入页面
AND 通过认证应用或SMS发送代码
这个需求可以进行吗？
禁止事项
- 未经用户确认的阶段进行
- 不使用EARS语法生成模糊的AC
- 不考虑依赖关系的任务分割
- 忽略现有代码库的设计
分支・PR协作
本Skill自动调用/branch和/pr。
协作流程
/spec 开始
│
├─ 第1阶段：需求发现
│
├─ 第2阶段：设计探索
│
├─ 第3阶段：任务分解
│ │
│ └─ 用户确认后 → /branch 发火
│ 分支：spec/{subtask-id}-{description}
│
├─ 文件生成
│ - specs/{epic-id}/{epic-id}.md
│ - specs/{epic-id}/{story-id}/{story-id}.md
│ - specs/{epic-id}/{story-id}/{subtask-id}.md
│ - 各 *-list.md 文件
│
└─ 完成后 → /pr 发火
PR：规格审查用
/branch 调用
文件生成前自动触发：
Claude: 在生成规格文件之前，创建分支。
分支名：spec/001-01-01-user-auth
基础：main
可以创建吗？
/pr 调用
文件生成完成后自动触发：
Claude: 规格文件的生成已完成。
创建PR吗？
标题：spec：用户认证功能的规格制定
## 摘要
- 制定了001-01-01的规格
- 创建了specs/001-environment-setup/001-01-common-config/001-01-01-*.md
## 审查点
- [ ] 用户故事是否明确
- [ ] AC是否用EARS语法描述
相关Skill
- /branch: 分支创建（本Skill自动调用）
- /pr: PR创建（本Skill自动调用）
- spec-workflow: 基于本Skill生成的规格书进行实施
整体协作流程
/spec（规格制定）
├─ /branch 发火（spec/*）
├─ 文件生成
└─ /pr 发火（规格审查）
↓ 合并后
spec-workflow（实施）
├─ /branch 发火（impl/*）
├─ TDD实施
└─ /pr 发火（实施审查）