需求定界

在开始设计或实施前，收敛会改变任务行为、范围、风险或验收方式的决策；目标是消除关键假设，不是进行无限追问或为每项小改动设置审批门槛。

触发与边界

出现任一情况时使用：

• 用户目标有多种合理解释，且不同解释会导致不同实现、数据范围或权限行为。
• 成功条件或必要边界无法从现有证据推导，且不同选择会实质改变交付；未显式写非目标或测试命令本身不触发澄清。
• 新功能、跨模块改动或不可逆操作缺少会影响方案的业务决策。
• 用户明确要求澄清、拆解需求或比较方案。

目标明确、影响局部且验证方式清晰的任务直接处理；能从代码、日志、规则或文档确认的事实先自行核对，不把检索工作交给用户。不要强制生成 Spec、ADR、待办或要求用户批准每一步。

澄清过程

1. 先建立事实基线：复用已知规则、实现、测试和约束，只读取填补关键缺口所需的内容，区分事实与待决事项。
2. 筛选关键决策：只保留会实质改变范围、行为、风险或验收的未决问题；其余采用合理假设并显式说明。
3. 逐项收敛：一次合并少量互不依赖的关键问题，说明影响并给出推荐选项；仅在答案决定后续问题时逐项询问。只暂停依赖答案的部分，继续独立工作；已授权的假设不重复确认。
4. 输出定界结论：用简短清单记录目标、非目标、验收标准、已决事项、仍在采用的假设，以及下一步需要的 Skill 或行动。

后续路由

• 用户只需要方案、比较或问题清单时，交付定界结论后停止。
• 已获实施授权时继续执行；未分析的共享行为或契约影响才需要 change-impact-analysis，根因未明才需要 systematic-debugging，需要行为回归保护才使用 test-driven-change。文件数量不作为触发依据。

由入口调用时返回结论和剩余缺口，由入口安排下一阶段；独立使用时在当前授权内推进，专项不可用时采用本 Skill 的最小流程，不为路由加载整套规则。

完成标准

在无需猜测关键业务决策的前提下，可以说明任务目标、边界和验收方式；仍有未决事项时，明确其影响与需要用户决定的内容，不宣称需求已完全确定。