用途
Requirements Clarity 用于在正式实现之前，把模糊、含糊的需求转化为可执行的产品需求文档（PRD）。它通过系统化的澄清对话，逐步补齐需求中的缺失信息，并以 100 分制评分体系衡量需求的清晰程度，直到评分达到 90 分以上才输出最终 PRD。
主要能力
- 模糊需求识别：自动检测模糊的功能请求（如“加个登录功能”“实现支付”“做个仪表盘”），以及缺少技术上下文、不完整规格、范围含糊等情况。
- 清晰度评分：采用 100 分制评分，分为四个维度：
- 功能清晰度（30 分）：输入/输出、用户交互、成功标准各 10 分。
- 技术具体性（25 分）：技术栈 8 分、集成点 8 分、约束条件 9 分。
- 实现完整性（25 分）：边界情况 8 分、错误处理 9 分、数据校验 8 分。
- 业务背景（20 分）：问题陈述 7 分、目标用户 7 分、成功指标 6 分。
- 差距分析：从功能范围、用户交互、技术约束、业务价值四个维度识别缺失信息。
- 交互式澄清：每轮提出 2-3 个聚焦问题，一次只处理一个类别，基于用户上一轮回答逐步推进，避免一次性抛出所有问题。
- PRD 生成：评分达到 90 分后，生成结构化 PRD 文档，包含需求描述、设计决策、验收标准、执行阶段等完整章节。
使用方式
该技能以对话方式工作，流程分为四步：
- 初始需求分析：解析用户需求，生成功能名称（kebab-case 格式），确定文档版本（默认 1.0），确保
./docs/prds/目录存在，并进行初始清晰度评估。 - 差距分析：识别功能范围、用户交互、技术约束、业务价值四个维度的缺失信息。
- 交互式澄清：每轮提出 2-3 个问题，用户回答后更新评分、记录新信息、识别剩余差距；若评分低于 90 则继续下一轮提问，达到 90 分以上则进入 PRD 生成。
- PRD 生成：将最终文档写入
./docs/prds/{feature_name}-v{version}-prd.md，使用 Write 工具创建或更新该文件。
PRD 文档结构包括：需求描述（背景、功能概览、详细需求）、设计决策（技术方案、约束、风险评估）、验收标准（功能验收、质量标准、用户验收）、执行阶段（准备、核心开发、集成与测试、部署），以及文档版本、创建时间、澄清轮次、质量评分等元信息。
适用场景
- 需求不明确、含糊的功能请求。
- 功能复杂、预计工作量超过 2 天的任务。
- 缺少技术栈、集成点、性能/安全约束等上下文的需求。
- 缺少验收标准、成功指标、边界情况、错误处理说明的规格。
- 范围边界不清（如“用户管理”具体指什么）、未区分 MVP 与后续增强、未说明“不包含什么”的需求。
限制
以下情况该技能不会激活：
- 已提及具体文件路径（如
auth.go:45）。 - 已包含代码片段。
- 已引用现有函数或类。
- 带有明确复现步骤的缺陷修复。
其他行为约束：不一次性提出所有问题；不在未确认的情况下做假设；评分未达 90 分不生成 PRD；不跳过任何必需章节；不使用含糊抽象的语言；不在用户未回应的情况下继续推进；不提前退出技能模式。
成功标准
- 清晰度评分 ≥ 90/100。
- PRD 所有章节内容完整充实。
- 验收标准可勾选（使用
- [ ]格式）。 - 执行阶段任务具体可操作。
- 用户批准最终 PRD，可交付开发。