prd-writer

用途

PRD Writer 用于通过引导式发现流程生成结构化的产品需求文档（Product Requirements Documents，PRD）。它适合在定义产品需求、梳理功能范围、准备技术方案时使用。

主要能力

该技能采用三阶段顺序工作流：discovery（发现）→ analysis（分析）→ drafting（起草）。流程中明确要求“绝不跳过发现阶段”，必须先访谈用户。

阶段一：发现（访谈）

不假设任何上下文，分阶段提问，而非一次性问完。

• 阶段 1——问题与受众：你在解决什么问题？目标受众是谁？他们有哪些痛点？
• 阶段 2——解决方案与功能：你提出的解决方案是什么？关键功能有哪些？与替代方案相比有何不同？
• 阶段 3——结构与范围：产品结构是什么（页面、屏幕、区块）？成功标准是什么？是否有已知技术约束？

进入分析前至少完成 2 个提问阶段，并按需追问。

阶段二：分析与范围界定

将用户输入综合为结构化发现：识别依赖与风险；定义非目标（明确不在范围内的事项）；暴露未知项（标记为 TBD）；在起草前向用户呈现综合结果以获取反馈。

阶段三：起草

使用模板 templates/prd.md，按以下 schema 生成 PRD，并将草稿呈现给用户审阅。

PRD Schema 包含：

1. 执行摘要：问题陈述（存在什么问题、面向谁）、建议解决方案（将要构建内容的高层描述）、成功标准（可衡量的 KPI，具体数字而非模糊目标）。
2. 产品定义：价值主张（标题——主要收益；副标题——支撑文本；关键收益 3-5 条）、目标受众（人物画像、痛点、目标）。
3. 用户体验与功能：用户故事（“作为[用户]，我想要[动作]，以便[收益]”）、验收标准（When/Then/Shall 格式）、功能列表及描述、非目标（明确不在范围内的事项）。
4. 技术规格：架构概览（高层系统设计）、集成点（API、数据库、认证）、安全与隐私（需求与约束）。
5. 风险与路线图：分阶段发布（v1.0、v1.1、v2.0，不以 MVP 框架表述）、技术风险（已知挑战）、未知项（标记为 TBD）。

使用方式

该技能以技能形式提供，具体安装命令与调用方式在现有资料中暂未提供。使用时需遵循其工作流：先完成发现访谈，再进行分析与范围界定，最后起草 PRD。输出保存到 .specs/docs/prd-{project-name}.md，若 .specs/docs/ 目录不存在则创建。

质量要求

需求必须具体且可衡量。资料中给出的对比例子：

• 差：“搜索应该快” / 好：“搜索在 200ms 内返回结果”
• 差：“易于使用” / 好：“新用户在 2 分钟内完成引导”
• 差：“直观的界面” / 好：“无需帮助文本的任务完成率高于 90%”

适用场景

适用于需要定义产品需求、梳理功能范围、准备技术方案与路线图的场景，尤其适合在项目早期通过结构化访谈明确问题、受众、解决方案与约束。

限制与注意事项

• 必须完成发现阶段，提问阶段不得少于 2 个。
• 不假设项目类型，需通过发现确定。
• 不包含视觉/设计方向（该部分属于 design-builder）。
• 不得使用模糊形容词作为需求（如“快”“易用”“直观”）。
• 未知项应标记为 TBD，而非编造约束。
• 分阶段发布应现实可行（v1.0/v1.1/v2.0，不以 MVP 框架表述）。

与其他技能的集成

design-builder：PRD 为文案提取和设计提取提供输入（第 1、2、3 节）。 spec-driven：PRD 为功能初始化提供输入（第 1、3、4、5 节）。