当用户需求模糊、术语不清晰时使用。通过交互式追问澄清领域概念，提取实体、流程和暗物质。由 /genesis Step 1 调用。
使用三维框架（系统设计、运行模拟、工程实现）系统性审查架构和系统设计文档，作为 challenge 工作流中的规范契约设计证据层。产出按严重度分级的发现，关联到具体文档段落。
综合 Probe 阶段所有分析（nexus-mapper, runtime-inspector），生成决策就绪的系统风险报告。
识别项目中的独立系统，定义系统边界。产出系统架构总览，为后续系统设计奠定基础。
为单个系统设计详细的技术文档。负责架构图、接口设计、数据模型、Trade-offs讨论等。
使用WBS方法将系统设计文档分解为层次化任务。支持依赖分析、追溯链、验收标准。
| name | spec-writer |
| description | 将模糊或高层需求转化为严格的产品需求文档（PRD）。适用于需求含糊、范围过大或表达停留在概念层的场景。 |
“软件开发最难的部分，不是如何实现，而是精确定义到底要实现什么。”
你的任务是消灭歧义。
references/prd_template.md，然后创建 .anws/v{N}/01_PRD.md。[ASSUMPTION]。在创建 PRD 之前，你必须：
在创建 PRD 之后，你必须：
5. 执行“10 维歧义扫描”，修复或标记所有 Partial / Missing 项。
6. 验证每条 User Story 都具备：优先级 / 独立可测 / 涉及系统 / 边界情况。
7. 确保 [NEEDS CLARIFICATION] 标签数量 ≤ 3（硬限制）。若超出，则采用合理默认值并加 [ASSUMPTION] 标签。
.anws/v{N}/01_PRD.mdreferences/prd_template.md：产品需求文档模板。起草 PRD 后，你必须从以下 10 个维度系统性扫描全文。这一步是为了用可重复、可穷尽的方法替代随意的“还有问题吗？”。
对每个维度，标记状态：Clear ✅ / Partial ⚠️ / Missing ❌
| # | 维度 | 检查内容 | 状态 |
|---|---|---|---|
| 1 | 功能范围与行为 | 核心目标 / 成功标准 / 明确排除项 / 用户角色区分 | |
| 2 | 领域与数据模型 | 实体、属性、关系 / 唯一性规则 / 生命周期与状态转换 / 数据规模假设 | |
| 3 | 交互与 UX 流程 | 关键用户路径 / 错误、空状态、加载状态 / 无障碍与 i18n | |
| 4 | 非功能质量 | 性能 / 可扩展性 / 可靠性 / 可观测性 / 安全与隐私 / 合规 | |
| 5 | 集成与外部依赖 | 外部服务失败模式 / 导入导出格式 / 协议版本假设 | |
| 6 | 边界情况与失败场景 | 负向场景 / 限流 / 并发冲突处理 | |
| 7 | 约束与权衡 | 技术约束 / 显式权衡记录 / 被否决的备选架构 | |
| 8 | 术语一致性 | 标准术语表 / 同义词在全文中的统一 | |
| 9 | 完成信号 | 验收标准是否可测 / DoD 是否可量化 | |
| 10 | 占位符与模糊词 | TODO 标记 / 未量化形容词（快、可扩展、安全、直观、健壮） |
规则：
Partial 或 Missing 项，按 影响 × 不确定性 排序，选取前 5 个向用户追问[NEEDS CLARIFICATION] 标签数量硬限制 ≤ 3；若仍超出，则采用合理默认值并加 [ASSUMPTION: ...]PRD 中的每条 User Story，在 PRD 被视为完成前，都必须通过以下检查：
| 检查项 | 要求 |
|---|---|
| 唯一 ID | 必须带 [REQ-XXX] 以便追踪 |
| 优先级 | 标记为 P0 / P1 / P2，且 P0 必须排前 |
| 独立可测 | 说明该故事如何独立演示和验证 |
| 涉及系统 | 列出具体系统 ID（必须与 02_ARCHITECTURE_OVERVIEW.md 对齐） |
| 验收标准 | 至少 1 条 Given-When-Then + 至少 1 个错误场景 |
| 边界情况 | 至少识别 1 个边界条件 |
| 无模糊感觉词 | 不允许出现未量化形容词（如快 → <100ms p99，可扩展 → 支持 N 用户） |
| 用户价值 | 用一句话描述对终端用户的价值 |
若任一 User Story 未通过检查，必须先修复，再交付 PRD。