requirement-clarifier

name	requirement-clarifier
description	需求澄清。功能：检测并澄清用户模糊描述，确保需求可拆解为具体任务。当出现以下场景时必须调用此skill：1)描述只有动作无对象（如"优化一下"）；2)缺少明确标准（如"做得更好"）；3)范围不明确（如"处理一下"）；4)存在冲突需求（如"要简单但功能全"）；5)缺少目标、范围或输出格式。

需求澄清

触发条件

显式模糊模式：

• 动作无对象："优化一下"、"改一下"、"调整一下"
• 动作无标准："做得更好"、"提高性能"、"加快速度"
• 范围不明确："处理一下"、"看看这个问题"
• 冲突需求："要简单但功能全"、"要快但不要改架构"
• 缺失关键信息：无目标、无范围、无输出格式

隐式模糊判断：

• 先结合上下文（代码、历史对话、文件结构）推断意图
• 仅在推断后仍存在不确定项时才询问用户

可拆解标准

需求必须同时满足以下条件才算"可拆解"：

• 目标明确：知道要达成什么结果
• 范围明确：知道涉及哪些文件/模块/功能
• 输出格式明确：知道最终交付物的形式
• 无歧义：不存在多种合理解读

澄清机制

阶段一：主动追问（同一模糊点最多2次）

• 必须主动提供选项 + 支持自定义输入
• 追问模板："关于「{模糊描述}」，我的推断是{推断结果}。请确认或补充：1)目标：{选项A/选项B/自定义} 2)范围：{选项A/选项B/自定义} 3)输出格式：{选项A/选项B/自定义}"

阶段二：计划确认（追问2次后仍不清晰）

• 按最佳理解生成执行计划展示给用户
• 用户可在此基础上修改，最多再修改2次
• 修改后重新展示计划供确认

阶段三：直接执行

• 计划确认阶段修改也达2次上限时，按当前最佳理解直接执行

输出格式

澄清完成后输出标准化需求描述：

- 目标：{明确目标}
- 范围：{涉及文件/模块}
- 输出：{交付物格式}
- 约束：{性能/兼容性等要求}
- 澄清记录：{简要记录推断和确认过程}

规则

• 不过度追问；上下文推断是核心优势，优先使用
• 用户表现出不耐烦（如"就这样吧"、"别问了"）→ 立即进入阶段二
• 同一模糊点：最多2次追问 + 2次计划修改