sdd-clarify

SDD 澄清——问得准确，一次构建

最省的 token，就是不用花在返工上的 token。含糊的请求未经澄清就直接实现，必然会浪费迭代（实现 → 出错 → 重新实现 → 重新审查）。这项技能会提前消除歧义：通过简短、精准的澄清，将模糊的需求转化为范围明确的 SDD 变更，让实现／审查循环只运行一次。本技能以 GitHub Spec-Kit's /speckit.clarify 和 Matt Pocock 的 grill-me 技能为蓝本（通过访谈达成共识，逐一厘清决策树的各个分支，并为每个问题提供推荐答案），并进行了精简，以节省 token。

何时使用

处理任何功能或 bug 请求时，都应在提出规范或修改代码之前使用。这一步为 /opsx:propose（或工作流的规范阶段）提供真正明确的目标。

澄清流程

1. 先以低成本收集上下文。 只阅读了解代码／规范中已经确定事项所需的内容——现有模块、相关规范、约定。不要询问用户仓库已有答案的问题。（快速读取／定位，不要深入钻研。）
2. 扫描以下维度的歧义（采用 Spec-Kit 的维度），只保留真正尚未解决且会影响实现方案的问题：
   • 功能范围与边界（包含哪些内容／明确排除哪些内容）
   • 数据模型／实体／持久化
   • 集成与依赖（涉及哪些服务／事件／契约）
   • 边缘情况与失败行为（失败时开放？错误？空值／限制？）
   • 非功能性要求（延迟预算、安全／授权、幂等性）
   • 术语／领域（消除多义词歧义，例如 bill 和 invoice）
3. 提问时考虑决策树，但控制 token 用量。 按决策树顺序提问：先问范围，因为它会决定后续问题。将相互独立的问题合并到一次 AskUserQuestion 调用中（每题提供 2–4 个可选项，将推荐选项放在首位并标注出来，让用户点击即可回答，无须长篇作答），以减少往返。当某个答案引出确实全新的依赖分支（只有根据该答案才有意义的后续问题）时，再进行一轮简短提问，厘清每个分支，不要猜测。不要将相互依赖的问题合并提问；不要询问代码已经确定的内容或有明显默认值的内容（说明默认值后继续）。如果请求没有歧义，什么都不要问，直接进入第 5 步。整个流程最多约 2 轮——没完没了地追问本身也是浪费。
4. 将答案纳入提案。 每个答案都要明确写入 OpenSpec 提案／规范（范围、决策、边缘情况）——以规范为准，而不是聊天记录。
5. 转入 SDD 流程：
   • 小型／单文件／bug 修复 → /opsx:propose，然后 /opsx:apply。
   • 大型／跨领域／聊天界面相关 → 使用已澄清的目标启动 sdd-feature-flow 工作流（运行期间无法向用户提问，因此必须在此处明确需求）。
6. PR 阶段的审查不属于本技能的职责——应由 pre-pr-greptile 技能负责：变更实现完成并准备创建 PR 时，该技能会运行 greptile review、验证 diff 是否匹配、进行分流处理并把关 PR。澄清 → 规范 → 实现 → greptile review → PR。

防护规则

• 不要过度提问。 问得太多本身就是浪费（浪费用户时间和 token）。最多提出 3–4 个精准问题；需求明确时则一个也不问。将推荐选项放在首位，让用户可以一键选择默认项。
• 绝不编造事实来填补空缺——如果未知信息至关重要，就提问；如果未知信息影响不大，就选择合理的默认值，并写入规范。
• 在此处消除的歧义 MUST 写入 OpenSpec 产物，不得只留在聊天记录中。
• 遵守 SDD 门禁：修改生产源代码仍必须基于此流程产出的有效变更。