Spec - 需求规格说明技能

将模糊的需求意图转化为清晰、无歧义的需求规格文档。

核心原则

不猜测：遇到任何模糊点，必须向用户提问澄清，绝不自行假设
不模糊：每个需求边界必须是确定的，In Scope / Out of Scope 必须明确列出
不写代码：绝不写任何代码，包括伪代码。只用自然语言描述需求行为
固定产出：输出到项目既有的需求目录；若无统一约定，建议使用 spec/<spec-name>/spec.md

工作流程

第一步：理解与澄清

阅读用户给出的需求描述
阅读项目级背景文档（如 PRD、roadmap、里程碑文档；如果存在），理解整体背景
阅读已有的需求文档，避免重复或冲突
列出所有不确定的点，逐一向用户澄清
反复澄清直到无任何歧义

第二步：撰写 Spec

按照下方固定模板撰写，写入对应功能的 spec.md。

第三步：用户确认

将产出交给用户确认，根据反馈修订直到用户满意。

固定模板

# <功能名称> 需求规格说明

> 状态：草稿 | 已确认
> 创建日期：YYYY-MM-DD
> 所属里程碑：如项目使用里程碑则填写，否则写"无"

## 1. 概述

### 1.1 功能简述
一句话说清楚这个功能做什么。

### 1.2 所属模块
标明属于哪个系统、子模块、包、程序集、服务或运行时区域。

### 1.3 关联文档
列出关联的 PRD 章节、roadmap、设计稿、其他 spec。

## 2. 用户故事与场景

### 2.1 目标用户
明确这个功能服务于谁。

### 2.2 用户故事
使用 "作为 <角色>，我希望 <行为>，以便 <价值>" 格式。

### 2.3 使用场景
描述 2-3 个典型使用场景，包含前置条件和期望结果。

## 3. 功能需求

### 3.1 输入
明确所有输入来源、格式、必填/选填。

### 3.2 输出
明确所有输出目标、格式、成功/失败的结果。

### 3.3 核心行为描述
用自然语言逐条描述系统在每个场景下的具体行为。
**禁止使用代码或伪代码。**

### 3.4 业务规则与约束
列出所有业务逻辑规则、限制条件、异常处理要求。

## 4. 非功能需求

### 4.1 性能要求
如有明确指标则列出，无则标注"无特殊要求"。

### 4.2 安全要求

### 4.3 兼容性要求

## 5. 边界与限制

### 5.1 明确包含（In Scope）
逐条列出本次需求范围内的内容。

### 5.2 明确排除（Out of Scope）
逐条列出本次明确不做的内容。

### 5.3 已知约束
列出技术或业务上的已知限制。

## 6. 验收标准（Acceptance Criteria）

使用 "Given-When-Then" 格式逐条列出：
- **Given** <前置条件>
- **When** <用户操作>
- **Then** <期望结果>

## 7. 开放问题（Open Questions）

列出所有尚未解决的问题，标注负责人和期望解决日期。
如全部已解决则标注"无"。

## 8. 变更记录

| 日期 | 变更内容 | 变更人 |
|------|---------|--------|

关键约束

绝不写代码：包括伪代码、代码片段、接口定义。这些属于 plan 阶段的职责
绝不猜测：宁可多问一轮，也不要用"可能"、"大概"、"应该"这类词
一个 spec 一个功能：不要在一个 spec 里塞多个不相关的功能
spec-name 命名规则：使用小写英文 kebab-case，如 user-auth、payment-retry