refine-spec

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. 不要一次问太多：每轮 1-3 个问题，逐个打磨
2. 问题要具体：问"拖拽到边界时，组件应该弹回还是吸附？"而非"边界情况你怎么看？"
3. 避免重复：已覆盖的维度不要重复提问
4. 尊重用户意图：用户说"不改了"就停止当前维度，进入下一个
5. 先问最重要的：按维度优先级 1→6 顺序检查
6. 每次更新后都要记录时间戳：方便追踪 spec 的演进历史
7. 如果用户说"跳过这个问题"：记录为待定项（在 spec 中标注 <!-- TODO: 待确认 -->）