用途：回答“这个需求到底要做什么”，建立对系统的正确理解，而非编写测试。输入包括 PRD、设计文档、API 文档、Bug、Issue、代码仓库；旁路场景可消费 exploratory-testing 的探索笔记（系统理解与风险清单）。输出落盘为 {项目}/需求模型.md，含澄清记录与用户裁决。
主要能力：按 Schema 组织需求模型，字段包括 goal、scope、roles、inputs、outputs、states、rules、exceptions、dependencies、open_questions；rules/states/exceptions 每条标注 evidence（level E0–E4 + source）；有代码仓库时主动索取路径、分支、改动范围与对比基线，代码作为静态事实最高来源，分支名与 commit 记入文件头部，续跑前核对分支未变。
使用方式：先收集盘点输入源，缺失项列入 open_questions；再逐文档提取要素；随后做一致性检查，发现文档内部、跨文档、文档与代码的矛盾；进入澄清检查点，按 clarify-pattern 的触发条件与九类歧义模式扫描，逐条独立提问，等待用户答复，不自行假设；最后按 Schema 落盘并交付，给下游一句话索引（模型路径 + 未裁决项数量）。
适用场景：拿到 PRD/设计文档需系统性理解需求再进入测试；多输入源需交叉核对、暴露矛盾与缺口；为 test-strategy / test-case-writing 准备结构化需求模型输入。
限制与边界：不产出用例（交给 test-case-writing）；澄清后仍模糊的项如实标注 open_questions，不硬猜；端到端测试整个需求应走 qa 编排；已有需求模型直接写用例走 test-case-writing；完全无文档且系统陌生先走 exploratory-testing。用户裁决记入 open_questions 并具最终裁决力，后续 skill 不得用代码推翻；出现新事实需重开裁决，不覆写旧记录。空字段需标注“已核对，无此类要素”。