用途
clarify-vague 用于把含糊或歧义的需求，通过假设驱动的提问，转化为精确、可执行的规格说明。当用户请求或需求不够明确、需要迭代提问才能落地时，应使用此技能。
典型触发场景包括：含糊的功能请求（如“添加一个登录功能”）、不完整的缺陷报告（如“导出坏了”）、说明不足的任务（如“让应用更快”）。
若要做策略/规划层面的盲点分析，应使用 clarify-unknown 技能；若要处理内容与形式之间的重构，应使用 clarify-metamedium 技能。
主要能力
核心原则：把假设作为选项
该技能主张把可能的解释作为选项呈现，而不是提出开放式问题。每个选项都是对用户真实意图的可检验假设。
- 较差做法：直接问“你想要哪种登录？”——开放式问题，认知负担高。
- 较好做法：给出“OAuth / 邮箱+密码 / SSO / 魔法链接”——让用户选择，负担更低。
协议流程
阶段 1：记录与诊断
逐字记录原始需求，并识别歧义：哪些地方不清楚或说明不足？需要做出哪些假设？哪些决定留给了个人解释？
阶段 2：迭代澄清
使用 AskUserQuestion 来消除歧义。每次调用最多可批量提出 4 个相关问题。每个选项都是关于用户意图的一个假设。
限制：总共 5-8 个问题。当所有关键歧义都已解决，或用户表示“足够好了”，或达到上限时停止。
示例 AskUserQuestion 调用：
questions:
- question: "Which authentication method should the login use?"
header: "Auth method"
options:
- label: "Email + Password"
description: "Traditional signup with email verification"
- label: "OAuth (Google/GitHub)"
description: "Delegated auth, no password management needed"
- label: "Magic link"
description: "Passwordless email-based login"
multiSelect: false
- question: "What should happen after registration?"
header: "Post-signup"
options:
- label: "Immediate access"
description: "User can use the app right away"
- label: "Email verification first"
description: "Must confirm email before access"
multiSelect: false
阶段 3：前后对比摘要
呈现转化结果：
## Requirement Clarification Summary
### Before (Original)
"{original request verbatim}"
### After (Clarified)
**Goal**: [precise description]
**Scope**: [included and excluded]
**Constraints**: [limitations, preferences]
**Success Criteria**: [how to know when done]
**Decisions Made**:
| Question | Decision |
|----------|----------|
| [ambiguity 1] | [chosen option] |
阶段 4：保存选项
询问是否将澄清后的需求保存到文件。默认位置为 requirements/ 或适合项目的目录。
歧义类别
| 类别 | 可能的假设示例 |
|---|---|
| 范围 | 所有用户 / 仅管理员 / 特定角色 |
| 行为 | 静默失败 / 显示错误 / 自动重试 |
| 接口 | REST API / GraphQL / CLI |
| 数据 | JSON / CSV / 两者 |
| 约束 | <100ms / <1s / 无要求 |
| 优先级 | 必须有 / 最好有 / 未来 |
规则
- 使用假设，而非开放式问题：每个选项都是对用户意图的一种合理解释。
- 不做假设：去问，不要臆断。
- 保留原意：只做精炼，不要改变方向。
- 最多 5-8 个问题：超过会造成疲劳。
- 批量提出相关问题：每次 AskUserQuestion 调用最多 4 个。
- 记录变化：始终展示前后对比。
适用场景
- 含糊的功能请求。
- 不完整的缺陷报告。
- 说明不足的任务。
限制
- 应始终使用 AskUserQuestion 工具，而不是用纯文本提出澄清问题。
- 问题总数上限为 5-8 个，以避免用户疲劳；达到上限需要停止。
- 该技能不适用于策略/规划盲点分析，也不适用于内容与形式的重构；这些分别应由 clarify-unknown 与 clarify-metamedium 技能处理。
- 默认保存位置为 requirements/ 或适合项目的目录，具体保存方式由用户选择决定。