| name | prd-analyzer |
| description | 内部步骤（Task 2），由 quickspec 编排器调用，不从用户直接触发。 对 PRD 内容进行 5-zone 结构化分析，提取功能、用户故事、业务实体、约束和验收条件。
|
| user-invocable | false |
| context | fork |
| allowed-tools | ["Read","Write","Edit"] |
步骤 2：PRD 分析
系统化地从 PRD 中提取结构化、可操作的信息。
输入输出
- 输入:
${ARGUMENTS}/prd-source.md（由 prd-loader 产出），${ARGUMENTS} 为编排器传入的 {workspace} 绝对路径（无尾部斜杠）
- 输出:
${ARGUMENTS}/prd-analysis.md
执行流程和规范
读取输入
使用 Read 工具读取 ${ARGUMENTS}/prd-source.md，获取 PRD 原始内容。从元数据头中提取 feature-name 用于后续引用。
输入验证
读取 PRD 后，执行以下验证：
- 文件存在性检查 — Read 工具失败 → 返回
STATUS: failed，ISSUES: "无法读取 prd-source.md"
- 内容长度检查
- 内容为空（0 字符）→ 返回
STATUS: failed，ISSUES: "PRD 内容为空"
- 内容过短（< 100 字符）→ 返回
STATUS: partial，WARNINGS: "PRD 内容过短，可能包含不完整信息"
- 元数据完整性检查 — 缺少 feature-name → 返回
STATUS: failed，ISSUES: "prd-source.md 缺少 feature-name 元数据"
验证通过后，对 PRD 内容应用五区域提取框架，按顺序处理每个区域。
区域 1：功能识别
提取每个独立的功能或功能性需求：
- 扫描功能标题 — 查找"功能"、"Feature"、"需求"、"Requirements"等标题的章节，或编号需求列表
- 划分功能边界 — 每个功能应该是独立可实施和可测试的
- 提取功能描述 — 该功能做什么，用一两句话概括
- 确定功能优先级 — P0/P1/P2、必须有/可以有、或 MoSCoW 标签。如果 PRD 中未显式标注，标记为"未指定"并在歧义列表中提出
每个功能的输出格式：
F{n}: <功能名称>
描述: <功能做什么>
优先级: <优先级>
关联功能: <相关功能的 F 编号>
区域 2：用户故事和场景
提取谁在什么上下文中做什么：
- 识别用户角色 — 终端用户、管理员、系统、第三方
- 提取用户故事 — 遵循"作为[角色]，我想要[操作]，以便[收益]"模式
- 识别场景 — 正常流程、边界情况、错误条件
- 提取交互流程 — 逐步的用户交互过程
对每个场景，确定：
- 前置条件（场景开始前什么必须为真）
- 触发条件（什么启动了该场景）
- 步骤（有序的操作序列）
- 预期结果（应该发生什么）
- 错误处理（出错时怎么处理）
区域 3：业务实体与交互需求
提取 PRD 中描述的业务层面的实体、属性、关系和交互需求（不提取技术实现细节）：
- 识别业务实体 — 在需求中反复出现的名词（用户、订单、商品）
- 提取业务属性 — PRD 中描述的实体属性（如"订单有金额、状态、创建时间"），使用业务语言记录，不推导技术类型
- 映射实体关系 — 业务层面的关联（一对多、多对多、组合），说明关系含义
- 提取交互需求 — PRD 中描述的系统交互（如"用户提交订单时需要校验库存"），记录交互意图而非 API 设计
- 识别状态流转 — 实体的业务生命周期（如订单：待支付→已支付→已发货→已完成），使用 PRD 中的原始描述
注意：本区域只提取 PRD 中已有的业务描述。具体的字段类型、校验规则、API 方法/路径/请求响应结构等技术规格由 spec-creator（步骤 4）结合代码库映射结果来生成。
区域 4：约束条件
提取非功能性和业务约束：
- 性能 — 响应时间、吞吐量、并发要求
- 安全 — 认证、授权、数据加密、审计日志
- 兼容性 — 浏览器/设备支持、API 版本控制、向后兼容
- 业务规则 — 校验逻辑、计算公式、工作流限制
- 合规性 — 监管要求、数据保留、隐私规则
注意：只提取 PRD 中明确提到的业务约束，不推导技术实现方案（如"使用 Redis 缓存"）。
区域 5：验收条件
提取每个功能的可衡量结果：
- 查找显式条件 — 寻找"验收标准"、"Acceptance Criteria"、"Definition of Done"
- 推导隐式条件 — 从功能描述和场景中推导
- 使条件可测试 — 每个条件必须是布尔型（通过/不通过）判定
- 确定验证方法 — 如何测试（单元测试、集成测试、手动测试、视觉检查）
- 覆盖所有场景 — 每个功能的验收条件应覆盖区域 2 中提取的所有场景，包括正常流程、边界情况和错误条件
处理不同 PRD 结构
PRD 有多种格式，需要适配提取方法。
各 zone 的详细提取信号（信号词、判断标准、注意事项），参考：
${CLAUDE_PLUGIN_ROOT}/skills/prd-analyzer/references/extraction-patterns.md — 按信息类型组织的提取信号和启发式规则
歧义检测
将以下情况标记为歧义（不使用 AskUserQuestion，写入产出文件的"歧义（需确认）"章节，由编排器在检查点统一展示给用户确认）：
- 模糊量词："快速"、"大量"、"很多" — 请求具体数字
- 缺失错误处理：场景只描述了正常流程 — 询问错误情况
- 未定义术语：领域行话没有解释 — 请求定义
- 冲突需求：两个需求互相矛盾 — 询问优先级
- 缺失边界情况：没有提及空状态、零结果或边界值 — 标记缺失
发现歧义时，以编号列表的形式提出具体问题，写入产出文件的"歧义（需确认）"章节。
重要：歧义不使用 AskUserQuestion 询问，由编排器在检查点统一展示给用户确认。
写入产出
使用 ${CLAUDE_PLUGIN_ROOT}/skills/prd-analyzer/references/output-template.md 作为结构模板，将提取的分析结果写入 ${ARGUMENTS}/prd-analysis.md：
- 按模板结构填充分析结果
- 使用 Write 工具写入文件
质量门禁自检
读取 ${CLAUDE_PLUGIN_ROOT}/skills/prd-analyzer/references/quality-gate.md，逐项核对产出物 ${ARGUMENTS}/prd-analysis.md 是否满足所有验收标准：
- 全部通过 — 继续，返回编排器
- 有未通过的项：
- 使用 Edit 工具修复产出文件
- 重新核对
- 最多重试 2 次
- 仍未通过则返回
STATUS: partial，ISSUES: "质量门禁未通过：{未通过项列表}"
返回编排器
完成所有工作后，输出以下格式的状态信息（不要包含其他内容）：
[STATUS: success | partial | failed]
[OUTPUT: prd-analysis.md]
[FEATURE-NAME: <从 prd-source.md 元数据提取>]
[WARNINGS: <警告列表，没有则为 none>]
[ISSUES: <阻塞问题列表，没有则为 none>]
[AMBIGUITY-COUNT: <歧义数量，无歧义则为 0>]
[SUMMARY: <一句话摘要，包含歧义数量提示>]
