prd-writerlisted
Install: claude install-skill songshishuang/Skills
# PRD Writer
## Overview
按 **7 节标准结构** 产出 AI 产品 PRD（Summary / Problem & Goals / Scope / Design / Rollout & Risks / Quality / Appendix）。
结构源自作者 V0.5 实际使用版本，借鉴 **Amazon Working Backwards / Basecamp Shape Up / Google Design Doc / Linear spec / Atlassian Poster** 等社区现代产品文档模式，将原 V2.x 的 13 节压缩为 7 节，治理元信息（修订/评审/参考链接）移到 frontmatter，业务核心 Design 章节权重从 1/13 提升到 1/7。
**配套交付 · 角色切片**：每次产出全本 PRD 后，自动派生 4 个角色切片（`for-coding` / `for-qa` / `for-bi` / `for-ops`）—— 解决"一份 PRD 撑 6 个消费者互相污染"的问题，让 AI 编码 agent 默认只读 `for-coding.md`。
**核心原则**：
1. 全本 7 节是 source of truth · 切片自动派生 · 切片只读
2. 章节"按场景必填"而非"全员必填"—— 不适用的节就**删**而不是标 N/A
3. AI 产品必备的 6 大缺口（业务目标 / 用户故事 / 数据埋点 / 评测指标 / 灰度上线 / 验收清单）仍然覆盖 · 仅重组归类
## 何时使用
- 写一份新版本的 PRD（如 "V0.9 需求"、"下个迭代的 PRD"）
- 把一段需求描述 / 会议纪要 / Figma 链接结构化为正式文档
- 升级旧 PRD 到 7 节标准结构
- **⭐ 从已有高保真原型反推 PRD**（HTML 原型 / Figma 链接 / 设计稿截图 / 多页面 demo）
- 用户问 "AI 产品 PRD 怎么写" 这类元问题
## 何时不用
- ❌ 一次性技术调研 → 用 doc-coauthoring
- ❌ 内部 RFC / 决策记录 → 用 doc-coauthoring
- ❌ 客户营销文档 → 直接 frontend-design 写 HTML
- ❌ 单个功能的 spec（< 1 屏内容）→ 直接写 markdown，不需要 7 节
- ❌ 工程文档 / API 文档 → 用对应技术文档模板
## 工作流（4 阶段）
### Stage 0：读项目 wiki（如存在）⭐
**触发条件**：项目根下存在 `docs/wiki/` 目录（由 `pm-wiki-maintainer` skill 维护）。
**目的**：把之前所有项目知识沉淀（PRD / 决策 / 概念 / 主题 / 竞品 / 角色）作为**先验上下文**，避免"重新发明轮子"。
**3 步**：
1. **读 wiki 索引**：`Read docs/wiki/index.md`
2. **判断本期 PRD 主题关键词**，drill 进相关页：
- PRD 涉及 X 业务 → 读 `topics/{X}.md`
- PRD 涉及新决策 → 读 `decisions/{相关主题}.md`（综合视图）
- PRD 涉及核心概念 → 读 `concepts/{概念}.md`
- PRD 涉及客户 / 竞品 / 角色 → 读 `ent