---
name: planning-write-specs
description: SpecPow planning-write-specs skill
---

# 编写规范

> 根据提案编写 Delta 规范（spec.md）

## 触发条件

- proposal 完成后需要编写规范
- 用户提到"写规范"/"spec"/"需求规范"

## 铁律

1. **Delta 格式** — 使用 ADDED/MODIFIED/REMOVED/RENAMED
2. **验收标准** — 每个需求必须有 Given/When/Then
3. **唯一 ID** — 每个需求有唯一标识

## 规范格式

```markdown
# 规范: [变更标题]

## ADDED Requirements

### REQ-001: [需求标题]
系统应当 [具体行为描述]。

**验收标准:**
- **Given** [前置条件]
- **When** [触发动作]
- **Then** [预期结果]

### REQ-002: [需求标题]
...

## MODIFIED Requirements

### REQ-010: [需求标题]
变更描述: [修改了什么]
原因: [为什么修改]

**更新后的验收标准:**
- **Given** ...
- **When** ...
- **Then** ...

## REMOVED Requirements

### REQ-020: [需求标题]
移除原因: [为什么移除]
影响: [移除后的影响]

## RENAMED Requirements

### REQ-030 → REQ-031: [旧名称 → 新名称]
重命名原因: [为什么重命名]
```

## 编写原则

1. **具体** — "系统应当在 3 秒内返回结果" 而非 "系统应当快速响应"
2. **可测试** — 每个需求都能写出测试用例
3. **无歧义** — 避免"可能"、"也许"等模糊词
4. **独立** — 需求之间尽量不互相依赖

## 红旗

- 无验收标准 → 必须补充
- 需求模糊 → 与用户确认
- 需求冲突 → 解决冲突后再继续
