prd-analyzer

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 后，执行以下验证：

1. 文件存在性检查 — Read 工具失败 → 返回 STATUS: failed，ISSUES: "无法读取 prd-source.md"
2. 内容长度检查
   • 内容为空（0 字符）→ 返回 STATUS: failed，ISSUES: "PRD 内容为空"
   • 内容过短（< 100 字符）→ 返回 STATUS: partial，WARNINGS: "PRD 内容过短，可能包含不完整信息"
3. 元数据完整性检查 — 缺少 feature-name → 返回 STATUS: failed，ISSUES: "prd-source.md 缺少 feature-name 元数据"

验证通过后，对 PRD 内容应用五区域提取框架，按顺序处理每个区域。

区域 1：功能识别

提取每个独立的功能或功能性需求：

1. 扫描功能标题 — 查找"功能"、"Feature"、"需求"、"Requirements"等标题的章节，或编号需求列表
2. 划分功能边界 — 每个功能应该是独立可实施和可测试的
3. 提取功能描述 — 该功能做什么，用一两句话概括
4. 确定功能优先级 — P0/P1/P2、必须有/可以有、或 MoSCoW 标签。如果 PRD 中未显式标注，标记为"未指定"并在歧义列表中提出

每个功能的输出格式：

F{n}: <功能名称>
  描述: <功能做什么>
  优先级: <优先级>
  关联功能: <相关功能的 F 编号>

区域 2：用户故事和场景

提取谁在什么上下文中做什么：

1. 识别用户角色 — 终端用户、管理员、系统、第三方
2. 提取用户故事 — 遵循"作为[角色]，我想要[操作]，以便[收益]"模式
3. 识别场景 — 正常流程、边界情况、错误条件
4. 提取交互流程 — 逐步的用户交互过程

对每个场景，确定：

• 前置条件（场景开始前什么必须为真）
• 触发条件（什么启动了该场景）
• 步骤（有序的操作序列）
• 预期结果（应该发生什么）
• 错误处理（出错时怎么处理）

区域 3：业务实体与交互需求

提取 PRD 中描述的业务层面的实体、属性、关系和交互需求（不提取技术实现细节）：

1. 识别业务实体 — 在需求中反复出现的名词（用户、订单、商品）
2. 提取业务属性 — PRD 中描述的实体属性（如"订单有金额、状态、创建时间"），使用业务语言记录，不推导技术类型
3. 映射实体关系 — 业务层面的关联（一对多、多对多、组合），说明关系含义
4. 提取交互需求 — PRD 中描述的系统交互（如"用户提交订单时需要校验库存"），记录交互意图而非 API 设计
5. 识别状态流转 — 实体的业务生命周期（如订单：待支付→已支付→已发货→已完成），使用 PRD 中的原始描述

注意：本区域只提取 PRD 中已有的业务描述。具体的字段类型、校验规则、API 方法/路径/请求响应结构等技术规格由 spec-creator（步骤 4）结合代码库映射结果来生成。

区域 4：约束条件

提取非功能性和业务约束：

1. 性能 — 响应时间、吞吐量、并发要求
2. 安全 — 认证、授权、数据加密、审计日志
3. 兼容性 — 浏览器/设备支持、API 版本控制、向后兼容
4. 业务规则 — 校验逻辑、计算公式、工作流限制
5. 合规性 — 监管要求、数据保留、隐私规则

注意：只提取 PRD 中明确提到的业务约束，不推导技术实现方案（如"使用 Redis 缓存"）。

区域 5：验收条件

提取每个功能的可衡量结果：

1. 查找显式条件 — 寻找"验收标准"、"Acceptance Criteria"、"Definition of Done"
2. 推导隐式条件 — 从功能描述和场景中推导
3. 使条件可测试 — 每个条件必须是布尔型（通过/不通过）判定
4. 确定验证方法 — 如何测试（单元测试、集成测试、手动测试、视觉检查）
5. 覆盖所有场景 — 每个功能的验收条件应覆盖区域 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：

1. 按模板结构填充分析结果
2. 使用 Write 工具写入文件

质量门禁自检

读取 ${CLAUDE_PLUGIN_ROOT}/skills/prd-analyzer/references/quality-gate.md，逐项核对产出物 ${ARGUMENTS}/prd-analysis.md 是否满足所有验收标准：

1. 全部通过 — 继续，返回编排器
2. 有未通过的项：
   • 使用 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: <一句话摘要，包含歧义数量提示>]