~ask

Trigger: ~ask [description]

~ask 是交互式需求澄清命令，用于在不写文件、不进入执行、不激活完整项目流程的前提下，通过一问一答帮用户厘清目标、比较方向、判断价值、收缩范围、挑战前提。 兼容别名：~idea（逐步废弃）。

铁律

• 只讨论，不编写实现代码，不创建项目文件，不执行实现操作
• 不创建 .helloagents/
• 不创建或更新当前项目存储中的 state_path；同样禁止更新知识库文件、方案包或项目级规则文件
• 不生成方案包
• 不执行会改变工作区或外部状态的命令
• 不默认使用子代理
• 每次只问一个问题，不一次性抛出多个问题
• 每个问题必须给出推荐选项和理由，不让用户从空白开始思考

交互模式

核心规则

一问一答，逐条推进：

1. 一次只问一个问题。不批量提问，不生成问题清单。问完一个、用户回答、再问下一个。
2. 优先选择题。每个问题给出 2-3 个选项，标注推荐项及理由。选项使用数字编号，格式遵循全局「选择确认」规则；用户回复数字即可选择，也可以直接输入自己的想法。
3. 你主动读代码库。如果答案能从现有代码中找到（命名规范、配置模式、现有抽象、类似实现），你自己去找，不打扰用户。连续解决多个问题而不需要用户输入才是好的 ~ask 会话。
4. 覆盖核心维度。在对话中自然覆盖以下维度，不分阶段、不填表：
   • 方向：有哪几种可行做法？各自优劣是什么？
   • 价值：这件事值得现在做吗？最痛的人是谁？不做会怎样？
   • 范围：最小可验证切口是什么？做多大的版本？先做哪一块？
   • 前提：哪些假设最可疑？如果前提不成立会怎样？最省成本的验证方式是什么？
5. 用户可随时重定向。用户说"其实都不是——我要的是这样"时，你立即沿新方向继续，不坚持原选项。

交互节奏

• 已有代码库：你先静默读 5-15 个相关文件，基于代码证据形成假设，再以选择题形式逐条确认
• 全新项目：直接从最高不确定性的决策开始问
• 每个问题用户通常 5-10 秒回答
• 整个交互澄清过程通常约 10 分钟

流程

1. 快速理解问题

• 用一句话重述用户当前要解决的问题
• 明确讨论目标：是"不知道有哪些做法"、"不确定值不值得做"、还是"不知道该做多大"
• 已有项目时，静默扫描相关代码（不向用户展示扫描过程），形成内部假设

2. 交互澄清（核心阶段）

按交互模式核心规则，逐条推进。默认从最高不确定性的决策开始：

• 方向不明确 → 先问方向
• 范围有争议 → 先问范围
• 前提可疑 → 先挑战前提
• 都不确定 → 先问最影响后续决策的那个

遇到以下信号时自然收束：

• 用户连续确认推荐选项，无额外补充 → 方向已收敛
• 关键决策全部有明确答案 → 可以汇总
• 用户说"可以了"、"就这样"、"开始做吧" → 立即汇总

3. 汇总决策

对话结束时，输出结构化选择摘要：

• 目标：要解决什么问题
• 选定方向：选了什么做法，为什么
• 范围边界：做多大、先做哪块、明确不做哪些
• 已验证的前提：确认了哪些关键假设，搁置了哪些
• 悬而未决：还有哪些决策需要在后续阶段进一步明确

摘要用简洁列表，不写段落叙述。

4. 给出升级路径

根据交互澄清的结果，推荐下一步：

• 已厘清方向，可以形成方案 → ~plan
• 已厘清需求，可以直接实现 → ~build
• 需要重型产品规格 → ~prd
• 想让 你 自动执行完整流程 → ~auto

如果用户在 ~ask 过程中转而明确要求写文件、改代码、创建知识库或执行命令，不在 ~ask 内偷偷写文件；改为按最合适的升级路径继续。

快速通道

用户明确表示"直接做，不用问我"、"按默认来"、"你决定"时，你 基于代码分析直接给出推荐方向和升级路径，跳过逐条交互。

输出要求

• 先给结论，再给依据
• 不做"点子堆砌"——不列一堆方向让用户自己挑
• 不把尚未确认的假设伪装成事实
• 不把"可以做很大"默认当成推荐答案
• 涉及视觉/交互时，选项必须具体到可执行特征