Product Requirement Craft
A Claude Skill for generating Problem Framing, SRD, and PRD documents through interactive dialogue. Three-tier progressive requirement document system.
Type: Claude Skill（兼容 Claude.ai / Claude Code / Cursor）
项目定位
一个通过对话式提问逐步收集项目需求信息，最终自动生成结构化需求文档的 Claude Skill。面向产品、设计、开发三方团队使用，覆盖从立项讨论到开发交付的完整需求链路。
核心能力
三层递进文档体系
支持生成三种文档，每一层是下一层的输入：
Problem Framing → SRD → PRD
要不要做？ 做什么方向？ 具体怎么做？
Problem Framing（问题定义）
-
6 个字段：WHO / WHAT Problem / WHEN / WHAT Job / Customer Benefit / Company Benefit
-
输出一段流畅的问题陈述 + 字段明细表
-
适用阶段：立项讨论、Kickoff
-
典型篇幅：半页 ~ 1 页 SRD（Solution Requirements Document）
-
10 个章节：Customer → Job to be Done → Benefit（客户/业务/品牌）→ Problem → Solution（标杆分析 + 前后对比 + Scope 边界）→ Success Metrics → Risks & Mitigation → Feedback Loops → Product Requirements（概要）→ UI/UX Requirements（概要）
-
适用阶段：方案评审、跨团队对齐
-
典型篇幅：3 ~ 8 页 PRD（Product Requirements Document）
-
7 大章节 + 可选章节：修订记录 → 需求背景 → 概要说明 → 产品需求（前端/数据逻辑/CMS 后台/后端接口/多语言/内容素材）→ 数据需求（埋点 + A/B Testing）→ 非功能性需求（性能/降级容错/ADA/SEO/安全）→ 上线策略
-
后端/接口需求分两层：PM 写业务概要，开发补技术细节
-
包含验收标准格式和责任矩阵（PM/设计/开发的 R-C-I 分工）
-
适用阶段：设计评审、开发交付、测试验收
-
典型篇幅：5 ~ 20+ 页
智能提问策略
不是逐字段填表，而是按思考层次引导：
| 层次 | 目标 | 提取信息 |
|---|---|---|
| 第一层：问题本质 | 理解核心问题和受影响的人 | WHO、WHAT Problem、WHEN |
| 第二层：方案方向 | 理解解决思路和边界 | WHAT Job、Solution、Scope、Benchmark |
| 第三层：验证方式 | 理解如何衡量成功 | Benefits、Metrics、A/B Testing |
自适应行为：
- 用户说得多 → 从回答中提取信息，跳过已覆盖的问题
- 用户说得少 → 逐步追问，每轮不超过 1-2 个问题
- 用户不确定 → 提供具体选项帮助决策
- 用户想跳过 → 允许，标记为 TBD
完整度评分（红绿灯系统）
生成文档前自动评估信息充分度：
| 状态 | 含义 | 行为 |
|---|---|---|
| 🟢 充分 | 能完整回答该字段的核心问题 | 直接生成 |
| 🟡 较薄 | 有方向但不够具体 | 提示用户，由用户决定是否补充 |
| 🔴 缺失 | 关键信息完全缺失 | 强制追问，不允许跳过 |
项目类型自动识别
根据用户描述自动判断项目类型，激活对应的可选章节：
| 项目类型 | 识别信号 | 激活章节 |
|---|---|---|
| 单页面/单组件 | 提到单个功能模块 | 无额外章节 |
| 跨页面流程 | 提到多页面、转化漏斗 | PRD §4.0 用户流程概览 |
| 分用户群差异化 | 提到不同用户群策略 | PRD §4.0 用户群定义 |
| 整体优化/改版 | 提到改版、分期交付 | SRD §5.4 分期规划 |
类型可组合，识别后会和用户确认。
多角色审查
文档生成后，从三个角色视角扫描遗漏：
| 视角 | 检查重点 |
|---|---|
| 🎯 产品 | 问题定义是否清晰？指标是否可衡量？Scope 是否明确？ |
| 🎨 设计 | 场景是否具体到可出设计方案？交互状态是否完整？跨平台差异是否说清？ |
| 🔧 工程 | 后端接口是否足够开始设计？数据来源和逻辑是否清楚？非功能性需求是否定义？ |
复盘机制
审查完成后自动输出：
- 哪些章节信息最薄弱，原因是什么
- 本次提问过程中有什么可以改进的地方
在 IDE 环境下，复盘内容追加到
docs/requirement-reviews.md。
技术架构
文件结构（渐进式加载）
.claude/skills/requirement-writer/
├── SKILL.md (130 行) ← 入口：工作流 + 决策树
└── references/
├── questioning-guide.md (157 行) ← 提问策略 + 评分标准
├── problem-framing-template.md (56 行) ← PF 模板
├── srd-template.md (134 行) ← SRD 模板
├── prd-template.md (257 行) ← PRD 模板
└── example-yami-homepage.md (39 行) ← 填写示例
遵循 Anthropic 官方 Progressive Disclosure 原则：
- 启动时只加载 name + description（~100 tokens）
- 触发后加载 SKILL.md body（~130 行）
- 根据文档类型按需加载对应 template
- 生成前重新读取模板（防止长对话 context 漂移）
设计原则
| 原则 | 实现方式 |
|---|---|
| 简洁优先 | 只写 Claude 不知道的内容 |
| 祈使句指令 | 告诉 Claude 做什么，不解释事物是什么 |
| 反馈循环 | 评分 → 追问 → 重新评分 → 生成 |
| 一层引用 | SKILL.md 直接指向 references/，无嵌套 |
| 长文件加 TOC | prd-template 和 questioning-guide 顶部有目录 |
工作流程
Phase 1: 确认文档类型 + 项目背景初探
↓
Phase 2: 分层提问收集信息（问题 → 方案 → 验证）
↓
Phase 3: 项目类型识别 + 可选章节确认
↓
Phase 4: 完整度评分 + 信息确认
↓ （🔴 → 回到 Phase 2 追问）
Phase 5: 重新读取模板 → 生成 Markdown 文档
↓
Phase 6: 多角色审查 + 复盘
↓ （需修改 → 回到 Phase 2）
完成
安装方式
| 环境 | 安装方法 |
|---|---|
| Claude.ai | 上传 .skill 文件：Settings → Customize → Skills |
| Claude Code | ./install.sh --personal（全局）或 ./install.sh --project（项目级） |
| Cursor | ./install.sh --cursor 或手动复制到 skills/ 目录 |
触发方式
自动触发关键词：PRD、SRD、Problem Framing、需求文档、产品规格、项目启动、kickoff brief、新功能想法、梳理需求、定义问题等。
手动触发（Claude Code）：/requirement-writer
与现有 PRD Skill 的差异化
| 维度 | 市面常见 PRD Skill | Product Requirement Craft |
|---|---|---|
| 文档层级 | 只生成 PRD | 三层递进：PF → SRD → PRD |
| 提问方式 | 3-5 个固定问题 | 分层引导式，自适应深度 |
| 质量控制 | 无或简单打分 | 红绿灯评分 + 红灯强制追问 |
| 项目适配 | 通用模板 | 4 种项目类型自动识别 + 可选章节 |
| 团队协作 | 面向 PM 单人 | PM + 设计 + 开发三方（含责任矩阵） |
| 后端需求 | 不涉及 | PM 概要层 + 开发技术层双层结构 |
| 审查机制 | 无 | 多角色审查 + 复盘 |