devflow-clarify-requirements

name	devflow-clarify-requirements
description	在技术设计前澄清软件交付需求，解决重要产品决策、隐含假设、范围边界、成功标准和未决分支。用于 DevFlow medium/large 的 REQUIREMENT 阶段，或功能请求过于模糊、无法安全设计时。只询问无法从项目证据中回答的问题；不实现、不提交、不写技术方案，也不调用计划类 skill。

DevFlow 需求澄清

把用户请求和项目证据整理为双方一致、可测试的需求边界。产品澄清与技术设计严格分开。

输入与角色

接收用户请求、项目规则、有边界的代码/知识检索结果，以及调用方指定的报告路径。

在 DevFlow 中由协调者在当前上下文依次完成证据检查、决策图、用户访谈和需求报告，不再创建独立需求分析 Agent。只有代码或知识检索范围明确且会产生大量无关上下文时，才启动只读 helper 并只接收事实摘要。

澄清流程

1. 用一段话复述期望结果，不虚构行为。
2. 只列会改变可观察行为、范围或风险的决策分支，不设固定数量。考虑结果、范围、用户交互、数据归属与生命周期、权限、兼容性、失败行为和成功标准；证据已明确且没有真实分支的内容不展开。
3. 对每个分支分类：
   • evidence-resolved：代码、文档或现有行为已经给出答案；
   • safe-default：存在可逆、低风险的默认值；明确写出该默认值；
   • user-decision：不同选择会实质改变可观察行为、兼容性、成本、风险或范围。
4. 先用当前上下文的定向检索解决证据问题；只有一次直接检索会带入大量无关上下文时才启动一个有边界的 devflow-code-explorer 或 devflow-knowledge-retriever，并把相关证据问题合并到同一提示。绝不让用户重新调查仓库事实。
5. 同一轮合并询问最多 3 个相互独立的 user-decision；存在依赖关系时才逐个询问。每题先给推荐答案和简短理由，适合时提供 2–3 个具体选项。
6. 完成当前决策组后再处理依赖分支。如果答案产生新的重要分支，把它加入决策图。
7. 备选方案会实质改变产品时，给出 2–3 种方案、取舍和推荐；实现细节留给 DESIGN。
8. 复述最终范围、排除项、可观察行为和验收场景。独立使用时按用户需要确认；在 DevFlow REQUIREMENT 中，报告写完并通过校验后必须由协调者展示摘要并取得一次明确确认，不能因为逐项问题已经回答就跳过最终确认门禁。

不要追求固定问题数量。简单任务可能无需提问或只需一个问题，复杂任务可能需要多个。当每个重要分支都已由证据解决、明确决定，或作为有负责人的非阻断未决问题记录后停止。

质量门禁

完成 REQUIREMENT 前确认：

• 用户结果和受影响角色明确。
• 范围内与范围外行为不会被合理地混淆。
• 相关时，数据归属、修改方式、权限和兼容性均已决定。
• 验收标准可从外部观察并可测试。
• 假设有证据，或明确标记为默认值。
• 没有答案只停留在“视情况而定”；依赖条件已解决或记录。
• 未决问题区分阻断项与非阻断项。

输出

只写调用方指定的路径。DevFlow 已在 start 时物化需求报告模板，应直接填充模板并删除所有 {{...}} 占位项，不重建标题或排版。独立使用且没有现成模板时，使用以下中文结构：

# 需求报告

## 目标与背景
## 范围
## 排除项
## 决策与理由
## 验收标准
## 假设与证据
## 未决问题

不要为了标题措辞或排版反复改写正确内容。不要提交代码、写入 docs/superpowers/specs、调用 writing-plans、生成技术方案或开始实现。

在 DevFlow 中，写完报告不代表 REQUIREMENT 已获批准。调用方必须先结束阶段并进入 awaiting_approval=REQUIREMENT，向用户展示摘要；仅在用户明确确认后执行带 --user-confirmed 的批准命令。