用途：在决定要构建某个功能后，通过交互式需求访谈把“要构建什么”钉死，产出可直接供 to-spec 合成 PRD 的决策记录，无需后续再提问。它属于需求澄清环节：brainstorm 决定是否做，本技能确定做什么，to-spec 负责写下来。
主要能力与流程：
-
先调研再提问。提问前阅读项目已有知识：仓库根目录 CONCEPTS.md 术语表（问题须使用其统一语言）、docs/adr/ 中的既有决策（视为输入而非重问对象，仅在有新证据时挑战）、功能涉及的模块、模式、测试与集成点。若文件缺失，记录缺口并从代码合成，不阻塞。任何问题先自问“代码、术语表或 ADR 能否回答”，能则去读，带结论而非问题回来。访谈中若出现新领域术语或发现术语过时，就地更新 CONCEPTS.md。
-
按角度拷问（无暴露的角度可跳过，只问会改变构建内容的问题）：角色与权限、边界情况与失败模式、范围边界（明确排除项）、顺序与依赖、数据生命周期、集成点、确实相关的非功能需求、迁移与回滚。同时并行两件事：按 security-gate 的 threat-model-lite 清单记录该功能暴露的安全行答案；为每个主要需求在尽可能高的接缝处命名可观察行为（供后续测试决策与切片验收使用）。
-
访谈机制：一次一个问题，若有 AskUserQuestion 则使用它，给出从代码中得出的具体选项加显式“Other”；先展示再确认（如“代码现在是 X，这是这里想要的行为吗？”）；琐碎确认可批量，但决策绝不批量；已确立的事实不重问。
-
退出与交接：运行“可写规格”测试——自主阶段会问的每个问题是否已答复、成为带默认值的显式假设或被移出范围；若有未决项则继续提问。最后在对话中给出紧凑决策记录：按角度的决策、安全答案、命名接缝及其可观察行为、带默认值的假设、显式 OUT 清单。交接语为“run to-spec”。
限制与注意：不要问探索可回答的问题；不要为效率批量决策；无新证据不重开 ADR 或此前答复；不要把 security-gate 行或 test-lens 规则复制进对话，只引用并记录答案；不要在没有决策记录时结束；不要滑入实现规划（文件级形态属于 coding-design-plan，在规格之后）。