版本：2.88.0

name: clarify description: “使用结构化的AskUserQuestion工作流程进行密集的需求澄清。在实施前收集MUST_HAVE（阻塞性）和NICE_TO_HAVE（可选）信息。使用场景：(1) 开始新功能实施，(2) 需求不明确，(3) 有多种可能的方法，(4) 在编写任何代码之前。触发器：/clarify, ‘clarify requirements’, ‘ask questions’, ‘gather requirements’.” user-invocable: true

Clarify - 密集提问（v2.37）

系统地使用TLDR语义搜索+AskUserQuestion工具收集需求。

v2.88关键变更（模型无关）

模型无关：使用在~/.claude/settings.json或CLI/env vars中配置的模型
无需标志：与配置的默认模型一起工作
灵活：与GLM-5, Claude, Minimax或任何配置的模型一起工作
设置驱动：通过ANTHROPIC_DEFAULT_*_MODEL环境变量选择模型

快速开始

/clarify  # 开始当前任务的密集提问

预澄清：TLDR语义搜索（v2.37）

自动 - 在提问之前，使用语义搜索理解现有代码：

# 查找现有相关功能（节省95%的token）
tldr semantic "$USER_TASK_KEYWORDS" .

# 示例：对于“添加认证”，查找现有的认证代码
tldr semantic "authentication login session user password" .

# 获取结构概览以获取上下文
tldr structure . --lang "$PRIMARY_LANGUAGE"

这有助于根据代码库中已有的内容制定更好的问题。

工作流程

MUST_HAVE问题（阻塞性）

这些必须在继续之前回答：

AskUserQuestion:
  questions:
    - question: "这个功能的主要目标是什么？"
      header: "目标"
      multiSelect: false
      options:
        - label: "新用户面向功能"
        - label: "内部重构"
        - label: "修复bug"
        - label: "性能优化"

需要覆盖的类别

功能需求
- 这应该做什么？
- 输入/输出是什么？
- 边缘情况？
技术限制
- 需要遵循的现有模式？
- 技术偏好？
- 性能要求？
集成点
- 现有代码交互？
- 需要维护的API？
- 数据库变更？
测试与验证
- 这将如何被测试？
- 验收标准？
部署
- 需要功能标志吗？
- 回滚策略？

NICE_TO_HAVE问题

接受默认值但仍提问：

AskUserQuestion:
  questions:
    - question: "实现偏好？"
      header: "方法"
      multiSelect: true
      options:
        - label: "最小变化"
        - label: "包含测试"
        - label: "添加文档"

问题模板

目标澄清

AskUserQuestion:
  questions:
    - question: "这解决了什么问题？"
      header: "问题"
      options:
        - label: "用户痛点"
          description: "直接面向用户的问题"
        - label: "技术债务"
          description: "代码可维护性"
        - label: "性能问题"
          description: "速度/资源使用"
        - label: "安全问题"
          description: "漏洞修复"

范围定义

AskUserQuestion:
  questions:
    - question: "范围是什么？"
      header: "范围"
      options:
        - label: "单个文件"
        - label: "单个模块"
        - label: "多个模块"
        - label: "跨系统"

优先级

AskUserQuestion:
  questions:
    - question: "优先级？"
      header: "优先级"
      options:
        - label: "关键（阻塞）"
        - label: "高（这个冲刺）"
        - label: "中（这个季度）"
        - label: "低（待办事项）"

集成

由/orchestrator在第1步调用
预步骤：tldr语义搜索（v2.37自动）
必须在CLASSIFY步骤之前完成
结果通知计划复杂性

TLDR集成（v2.37）

阶段	TLDR命令	目的
提问前	`tldr semantic "$KEYWORDS" .`	查找相关代码
上下文收集	`tldr structure .`	代码库概览
依赖项检查	`tldr deps "$FILE" .`	影响分析

代理团队集成（v2.88）

最佳场景：纯代理团队（原生）

这个技能使用纯代理团队与原生协调 - 不需要自定义子代理专业化。

为什么这个技能选择场景A

澄清主要是顺序提问工作流程
AskUserQuestion是主要工具，所有代理都可用
没有特别的并行研究要求
原生代理类型足以收集需求
复杂度低，执行速度快

配置

TeamCreate：可选，用于简单的澄清任务
任务：使用原生代理类型（不需要ralph-*）
钩子：如果需要，TeammateIdle + TaskCompleted可用
简单：设置开销小

工作流程模式

TeamCreate （可选）
  → AskUserQuestion收集需求
  → 原生代理执行澄清
  → 完成

何时足够

顺序需求收集
简单的澄清工作流程
不需要特别的研究
优先选择快速的互动会话

反模式

永远不要在未回答MUST_HAVE问题的情况下继续
永远不要假设用户意图
永远不要跳过功能的澄清
永远不要一次问超过4个问题（AskUserQuestion限制）