| name | refine-spec |
| description | 循环向用户提问,持续收集补充意见来打磨 Spec 文档,直到用户明确确认全部 OK 才停止并输出完整结果。当用户要求"完善 spec"、"补充需求"、"评审 spec"、"继续细化"时触发。 |
| allowed-tools | Read(*), Bash(ls:*, cat:*), Write(*), Edit(*), Glob(*) |
| metadata | {"author":"tangjiahui","version":"1.0.0"} |
Refine Spec
以循环提问的方式不断收集用户补充意见,逐轮打磨 Spec 文档,直到用户明确确认无需补充后才停止。
触发条件
当用户提到以下内容时调用此 skill:
- "修改/完善/补充 spec"
- "评审/review spec"
- "继续细化需求"
- "帮我打磨 spec"
前置条件
必须存在 Spec 文件
ls .claude/tmp/spec/*.md 2>/dev/null
- 存在 → 选择目标 spec,进入提问循环
- 不存在 → 报错停止
❌ 错误:Spec 文件不存在(.claude/tmp/spec/ 目录下无 .md 文件)。
请先用 write-spec 生成 Spec:
「帮我写 spec:<你的需求>」
执行流程
整体循环
┌──────────────────────────────────────┐
│ 1. 读取当前 spec │
│ 2. 分析缺口,准备 1-3 个问题 │
│ 3. 向用户提问 │
│ 4. 用户回答 │
│ 5. 用 Edit 更新 spec │
│ 6. 追问"还有其他需要补充/修改的吗?" │
└──────────────────────────────────────┘
│
┌─────────┴─────────┐
│ 用户有补充 │ 用户表示"OK/没问题/可以了"
▼ ▼
回到步骤 1 停止循环,输出本轮所有变更摘要
提问维度
每次迭代从以下维度中选 1-3 个最需要补充的方向提问:
| 序号 | 维度 | 检查逻辑 |
|---|
| 1 | 范围边界 | 功能边界是否清晰?做什么/不做什么是否明确? |
| 2 | 功能拆分 | 功能点粒度是否合理?优先级(P0/P1/P2)是否正确? |
| 3 | 技术落地 | 涉及模块/文件是否遗漏?技术方案是否可执行? |
| 4 | 边界条件 | 空数据/加载态/错误态/极端值是否覆盖? |
| 5 | 兼容影响 | 对已有功能的影响是否分析?是否需要迁移? |
| 6 | 验证方案 | 验证步骤是否具体可执行?回归范围是否完整? |
原则:
- 已有充分覆盖的维度跳过不问
- 每次最多 3 个问题,避免信息过载
- 问题要具体,不能泛泛问"还有什么补充"
- 最后一轮只问一次"还有其他需要补充/修改的吗?"
更新 Spec
每轮用户回答后,用 Edit 工具精确修改 spec 文件中的对应位置。同时更新文件头部的时间戳:
> 创建时间: 2026-07-20 | 状态: draft | 最后更新: 2026-07-20 15:30
停止条件
用户给出以下任一信号时停止循环:
| 信号 | 示例 |
|---|
| 明确确认 | "没问题了"、"可以了"、"就这样"、"OK"、"确认"、"通过"、"没有" |
| 转入下一步 | "生成 plan"、"开始实现"、"执行"、"拆分步骤" |
输出结果
停止后,输出本轮所有变更摘要:
## Refine 完成
**Spec**:`.claude/tmp/spec/<name>.md`
### 本轮变更
| 轮次 | 维度 | 变更内容 |
|------|------|----------|
| 1 | 边界条件 | 补充了空数据态处理方案 |
| 2 | 功能拆分 | 将 Step 2 拆分为两个子功能点 |
| ... | ... | ... |
### 当前 Spec 状态
- 状态:ready(可进入 write-plan)
注意事项
- 不要一次问太多:每轮 1-3 个问题,逐个打磨
- 问题要具体:问"拖拽到边界时,组件应该弹回还是吸附?"而非"边界情况你怎么看?"
- 避免重复:已覆盖的维度不要重复提问
- 尊重用户意图:用户说"不改了"就停止当前维度,进入下一个
- 先问最重要的:按维度优先级 1→6 顺序检查
- 每次更新后都要记录时间戳:方便追踪 spec 的演进历史
- 如果用户说"跳过这个问题":记录为待定项(在 spec 中标注
<!-- TODO: 待确认 -->)