requirement-clarification

name	requirement-clarification
description	用于仓库需求澄清。当用户明确要求“需求澄清”“重新澄清”“继续澄清”“帮我澄清需求”“重新梳理需求边界”，或在设计、规划、实现前提出类似澄清诉求时使用。

需求澄清

核心目标

基于用户原始需求、当前仓库实现、已有文档和必要的互联网搜索，输出能帮助用户确认范围与决策点的澄清结果。

澄清纪律

• 先从用户要达成的目标、使用场景和成功标准定义需求，再说明现有代码结构如何支持或限制该目标；禁止把仓库当前模块边界直接当作需求边界。
• 需求澄清必须首先聚焦当前待澄清需求本身；历史需求文档、既有计划和过往边界约束只能作为参考背景，禁止默认把它们放在第一优先级。
• 禁止将历史需求中的“非范围”“暂不实现”“不引入依赖”等负向边界带入当前需求，作为当前需求的限制条件或评估证据。
• 如果当前需求范围与历史需求的约束边界存在冲突，必须把冲突点列为用户决策问题；禁止用“默认兜底”“降级实现”“兼容旧边界”等路径直接写入澄清文档。
• 所有需要用户决策的问题必须在对话中直接询问用户，并等待用户明确决策；绝对禁止将任何待决策问题直接写入需求澄清文档。
• 只允许把用户已经明确决策的问题写入需求澄清文档；如果仍存在未决问题，先停止写文档并继续提问。
• 遇到复合型需求时，先澄清关键概念在用户场景中的含义、边界和相互关系，再讨论实现分层；禁止未经确认就把用户概念替换成常见技术模式。
• 行业实践、常见架构模式和既有实现只能作为参考材料；引用它们时必须回到用户原始场景校准，禁止用通用模式覆盖用户目标。
• 如果用户纠正澄清方向，先停止沿用被否定的拆分方式，重述修正后的目标，并说明之后将按该目标重新组织澄清。

执行流程

1. 先理解用户的原始需求，识别目标、约束、成功标准和不确定点。
2. 遇到不确定的生僻名词、外部术语、产品名、规范或平台概念时，先搜索互联网；搜索后仍不确定再问用户，禁止猜测。
3. 搜索仓库相关代码和文档，优先使用 rg 和 rg --files。
4. 搜索代码仓时避开环境、缓存和构建目录，例如 node_modules、__pycache__、.venv、.git、dist、build。
5. 阅读与需求相关的源码、设计文档、计划文档、需求澄清文档和项目说明。
6. 对照历史需求文档时，只提取与当前需求相关的事实、已确认约束和潜在冲突；过滤历史需求中的“非范围”“暂不实现”“不引入依赖”等负向边界，发现真实冲突时停止写入结论，先请求用户决策。
7. 如果用户说“重新澄清”或“继续澄清”，复用已有调研结论，只针对新增问题补充互联网搜索、代码搜索和文档阅读。
8. 识别需求中适合图示表达的部分，包括 UI 布局、页面流转、状态转移、模块关联、数据流和执行流程。
9. 输出澄清结果前，先检查是否仍存在待决策问题；如果存在，必须在对话中提问并等待用户确认，禁止把待决策问题写入任何需求澄清文档。
10. 输出澄清结果；不要进入设计文档、开发计划或实现，除非用户明确要求。

输出结构

按下面顺序输出：

1. 需求理解：用自己的话说明用户要达成什么目标。
2. 仓库现状关联：说明当前实现、文档或模块与该需求的关系。
3. 范围确认：列出本轮建议纳入和不纳入的范围。
4. 需要决策的问题：仅在确实需要用户判断时提出，最多 5 个；这些问题只能出现在对话中，不能写入需求澄清文档。

图示表达

• 需求涉及 UI 设计、状态转移、模块关联关系、数据流或执行流程时，必须优先用示意图、流程图、状态图或关系图辅助澄清。
• 优先使用 Mermaid 图；如果 Mermaid 会让内容变复杂，使用简洁 ASCII 图或分层列表图。
• 图示要表达需求关系和边界，不替代文字结论；图下用 1 到 3 条说明解释关键节点、方向和待决策点。
• 不为简单单点需求强行画图；只有图示能降低理解成本时才使用。

提问规则

• 只提出和需求有明显关系的问题，禁止为了显得严谨而提问。
• 每个问题都给出一个推荐方案和一个备选方案。
• 推荐方案要直接、可执行；备选方案只覆盖真实存在的另一条路。
• 提问必须发生在写入需求澄清文档之前；用户未明确决策前，禁止把问题、选项或未定结论落盘到文档。
• 如果不需要用户决策，直接说明“当前不需要额外决策”，并给出已确认的范围。

边界

• 不替代 design-plan-doc-writer：需求边界稳定后，才进入设计文档和开发计划。
• 不替代 brainstorming：只有用户要共创方案或存在显著方案权衡时，才切到头脑风暴。
• 不替代实现、调试或评审技能：本技能只负责需求澄清。