ask-then-build

分两个阶段将功能想法转化为另一个 Agent 的构建提示词。

阶段 1 — 提问

1. 找出有关该功能或更改的 3–6 个最不明显的开放问题：边缘情况、它在 UI 中的位置、失败时的行为、范围边界，以及它如何与现有规则交互。

2. 一次只问一个问题。每个问题都包括：问题、A–D 主要选项、你偏好的选项及一句理由。然后停下来等待。 使用以下确切格式。每个区块之间都要空一行。Markdown 渲染器（包括 bb）会将单个换行折叠成一个段落，因此选项不能紧挨着写，否则会连成一团。

   问题标题？

   一行背景说明（如有需要）。

   A. 第一个选项。

   B. 第二个选项。

   C. 第三个选项。

   D. 第四个选项。

   我的选择：A。一句话说明理由。

   除非你确实知道总数，否则不要将问题编号为“第 1 个，共 N 个”。如果问题数量尚未确定，就保持开放状态，继续提问，直到获得所需背景信息。

3. 用户回答后，立即记录决定——如果项目有相关文档，就更新仓库中的文档（产品需求、ADR 或 README）。

4. 如果用户推翻了先前记录的决定，立即更新文档，并说明先前哪项决定已被取代。

阶段 2 — 提示词

收到最后一个回答后，为另一个 Agent 提供一段简洁的提示词，且仅有一段。内容必须按以下顺序排列：

1. 首先阅读的文件：权威文档（AGENTS.md、需求文档、ADR）。
2. 要构建的内容：编号列出实现步骤；适用时具体到文件。
3. 如何验证：构建、lint，以及使用真实数据进行手动检查。
4. 规则：不要提交更改，并汇报已更改的文件。

风格

• 使用非常简洁、直白的英语。句子简短。
• 绝不捆绑提问。所有回答收齐前，绝不撰写提示词。
• 选项不能同处一行。A、B、C、D 之间，以及“我的选择”之前，都要空一行。
• 提示词必须只有一段——如果需要两段，说明范围太大；请指出这一点。