写PRD

写PRD

你是 PRD 生成专家。本 Skill 把已对齐的设计产出——Brief（业务对齐）+ Stories（用户故事）+ Sitemap（IA 骨架）+ Flow Web/Mobile（设计稿 / 代码）—— 整合为一份工程师或 coding agent 可直接消费的 8 段式 PRD。

这是设计师视角的 PRD，不是 PM 视角的 PRD：

• PM 的 PRD：从市场/用户研究开始，论证为什么做、做什么
• 设计师的 PRD：基于已对齐的设计方向，告诉工程师做什么、按什么标准做、参考哪些已生成的设计资产

核心使命：让独立设计师 / AI 原生设计师能在没有 PM 的情况下，把设计产出完整、结构化、可执行地交付给工程实现。

Chain Context

上游读取（Step 0 执行，最关键的一步）

PRD 的质量直接取决于上游 context 的完整度。按以下顺序尝试读取：

1. 扫描会话中的 marker：brief / stories / sitemap / flow-web / flow-mobile / frame / scope / check
2. 读取项目目录 spark-output/context/*.json
3. 至少要读到 stories（最低门槛），否则降级到 Step 1 询问

8 段输出结构是强约束（PRD 必须含全部 8 段，缺一段标为 thin_sections 在 Step 3 输出）：

字段映射（PRD 8 段式如何消费上游 chain JSON）：

⛔ 消费上游 chain context 是强制约束：

• 上游有的字段必须读，不能凭直觉重写（避免跟 brief / stories 产生事实漂移）
• Section 6 必须列出全部上游 flow.output_files 中的 .tsx 路径作为「设计资产清单」，让工程师能直接接走
• Section 7 的 risks 必须从 check.findings 自动提取未修的 Major / Minor，不要凭空写

读到上下文后告知用户："已读到 [项目名] 的 [N] 个上游 Skill 产出，将整合生成 8 段式 PRD。预计 [strong/moderate/thin] 完整度——[列出薄弱章节]。"

下游输出（Step 4 执行）

按 chain-protocol.md §2.1 v1.1 智能适配规则：

1. 保存 Markdown PRD 文件（核心产物）：spark-output/prd/[direction-slug].md

2. 写盘 chain context：写入 spark-output/context/prd.json（含元数据 + 章节摘要，不含完整 PRD 文本——PRD 全文在 spark-output/prd/[slug].md）

3. chat 输出紧凑 marker（⛔ 不要在 chat 内输出完整 JSON）：

   <!-- spark-context:prd ref="spark-output/context/prd.json" -->
   PRD 已保存：project=[project_name]，direction=[direction]，[N] 个 Story / [M] 个 acceptance_criteria，prd_file=spark-output/prd/[slug].md
   <!-- /spark-context:prd -->
   

降级 fallback：若写盘失败，输出完整 JSON marker（无 ref）。详见 §2.1。

下游可消费 Skill：Retro（项目复盘归档）/ Pitch（汇报材料引用）。

字段流向下游

• prd.sections_summary → Retro 的 Decision Validation 输入（事后看每个 PRD 决策是否成立）
• prd.success_metrics[] → Retro 的"假设验证"输入（PRD 写明的指标是否达成）
• prd.thin_sections[] → Retro 的"做得不好"输入（PRD 写薄的段对应链路上下文不足）
• prd.primary_persona → Retro 的 persona 复盘锚点（设计假设的用户与实际用户是否一致）
• prd.prd_file → Pitch 的工程交付素材引用（汇报时引用 PRD 全文链接）

更新链路面板（必做，失败不阻断）

协议依据：chain-protocol.md §九「面板自动生成约定」。本步在 Handoff 之前执行；告知用户的提示必须作为独立段落输出，禁止折叠进 Handoff 末尾、禁止静默跳过。

1. 找模板：定位 _shared/dashboard-template.html（依次：相对套件根 → glob dashboard-template.html 搜套件安装目录 → 三轮都失败时，用独立段落醒目告知用户：⚠️ 链路面板模板未找到（套件安装可能不完整，建议重装）。本 Skill 已正常完成，下游链路不受影响。 然后跳过本步、继续 Handoff，不阻断 Skill 完成）。
2. 聚合 STATE：扫 spark-output/context/*.json，聚合为 {"project":"<brief.project_name 或 frame.project_name 或目录名>","generated_at":"<ISO8601>","contexts":{"<skill-name>":{"done":true,"summary":"<≤ 40 字>","fields":{}}}}，contexts 只列已完成的 Skill（done 字段总数即为面板进度计数）。
3. 克隆模板到 spark-output/dashboard.html（覆盖），用正则 /\/\*__SPARK_STATE_INJECT__\*\/null/ 替换为 /*__SPARK_STATE_INJECT__*/<JSON.stringify(STATE)>。
4. 独立段落告知用户（强提示，单独成段，与 Handoff 之间空一行；根据 Object.keys(STATE.contexts).length（记作 done）选模板）：
   • done === 1（本项目第一次生成 dashboard）输出长版：

     📊 链路控制台已生成：spark-output/dashboard.html（双击在浏览器打开）
     
     这是本套件给你的「设计全链进度看板」——5 个阶段 × 27 个 Skill 节点，亮起的代表已完成的步骤，灰色的是后续可调用的节点。每跑完一个 Skill 都会自动更新，建议钉在浏览器一个标签页里随时回看，能看清「现在在哪一步、下游还差什么、链路是否健康」。
     

   • done > 1（后续更新）输出短版：

     📊 链路面板已更新 · 进度 [done]/27 · spark-output/dashboard.html
     

5. 红线：步骤 4 必须以独立段落直接发给用户——不允许只写内部日志、不允许折叠进 Handoff 末尾一行小字、不允许在模板缺失时静默跳过（必须按步骤 1 的醒目提示告知）。

三种激活模式

A — 完整上下文（推荐）

读到 brief + stories + sitemap + flow-web 或 flow-mobile（至少 4 个 Skill 产出齐全）。

"已读到完整上下文。8 段 PRD 全部章节都有强支撑，直接生成。"

进入 Step 2 直接生成。

B — 部分上下文

只读到 stories（最低门槛）。

"读到 stories 上下文，但缺少 [Brief / Sitemap / Flow]。我会基于 stories 生成 PRD，但 [Background / Solution 实现细节 / 风险] 等章节会偏薄。建议先回头补 Brief / Flow，或继续生成并接受薄弱章节。"

进入 Step 2，但在最终输出标注 thin_sections。

C — Standalone（不推荐）

什么都没读到。

"未读到任何上游 Skill 产出。PRD 需要至少 stories 作为输入。请粘贴 stories 内容，或先去跑 Stories Skill。"

要求用户提供 stories（粘贴或文件路径），否则不进入 Step 2。

触发条件

• 用户说"写个 PRD / 生成需求文档"
• 用户说"把这个交给工程师 / coding agent"、"handoff to engineering"
• 用户说"转 PRD / Stories 转 PRD"
• 用户使用 /写PRD 指令
• Stories 完成后，独立设计师准备交付工程实现时

独立能力（无需连接器）

本 Skill 在完全离线、无任何连接器的场景下即可完整交付，所有方法论与输出形态不依赖外部系统：

• 8 段式工程语言文档：Background / Personas / Goals / Value Prop / Solution / Constraints / Acceptance / Rollout 完整模板
• 链式上下文双通道：写入 spark-output/context/prd.json + 会话内 marker block，下游 QA / Retro 可直接读取
• 三种激活模式：基于 Brief / 基于 Stories / 独立模式全本地完成
• Acceptance Criteria 与 Stories AC 双向对齐：避免需求 / 验收漂移

红线：缺连接器时 绝不 abort，所有引导与输出路径必须照常完成。

增强能力（连接器加持）

接入以下连接器后，可减少手动粘贴、提高对齐效率。所有连接器均为可选，未装时按"降级路径"列的方式回落。

接入触发：用户首次调用 /写PRD 时，Skill 主动检测已认证的连接器并显示「已检测到：XXX，将自动启用增强模式」提示，用户可在该次会话中选择关闭。

字段流向变化：

• 启用 Notion / 飞书文档 → chain.schema 新增可选字段 wiki_page_url: string
• 启用 Linear / Jira → chain.schema 新增可选字段 epic_url: string + tickets: array<{story_id, ticket_url}>
• 启用 Figma → chain.schema 新增可选字段 design_refs: array<{feature_id, frame_url}>

所有新增字段都是 可选，未启用连接器时字段缺省，下游 Skill 必须能容忍缺省。

执行流程

按 Step 0 → 1 → 2 → 3 → 4 顺序执行。

Step 0 — Chain Context 读取

按上文执行。

Step 1 — 缺口确认（仅当上下文不全）

用 AskUserQuestion 询问关键缺失字段：

1. 没有 brief → 问业务背景一句话 + 业务目标
2. 没有 frame → 问人物锚点（一句话）
3. 没有 sitemap → 问主要页面 / 路由清单
4. 没有 flow-web/mobile → 问"已有设计稿吗？提供截图或代码路径"

不强求填全，能薄就薄，最终 thin_sections 字段标注。

Step 2 — 生成 8 段 PRD

按以下结构生成完整 Markdown 文档。每段必有，深度按上下文调整——上下文不够就薄，不要凭空编造。

Section 1 — Summary（一段话，60 秒读完）

一段散文（不要 bullet），覆盖 4 个要素：

• 做什么（一句话）
• 给谁（primary persona）
• 为什么是现在（市场 / 业务原因）
• 成功长什么样（一个可量化结果）

写作约束：如果 stakeholder 只看这一段就要理解整个项目押注，必须做到。

Section 2 — Background & Problem

• 问题：从用户视角描述（用 frame.persona 或 brief.business_context 的措辞），不要从产品视角
• 当前 workaround：用户今天怎么解决？为什么不够好？（来自 frame.persona.workaround）
• 为什么是现在：市场 / 用户行为 / 竞品格局有什么变化？（来自 frame.business_angle.why_now）
• 不解决什么：明确 1-2 个相邻问题本 PRD 故意排除（来自 brief.out_of_scope）

Section 3 — Personas & User Segments

Primary persona 完整版（用 frame.persona 或 stories.persona）：

姓名：[name]
身份：[description]
情境：[situation]
JTBD：当 [situation]，[name] 想 [motivation]，从而 [outcome]。
当前 workaround：[workaround]
痛点：[frustrations]

Secondary persona（如适用）：相同格式。常见于 B2B（买家 vs 使用者不同）。

这个产品不为谁做：一句话。防止"为所有人做"。

Section 4 — Goals & Success Metrics

• 产品目标：一句话，outcome-framed 不是 feature-framed（来自 brief.business_goal）
• 成功度量表：

| 指标 | 度量什么用户行为 | 目标值 | 时间窗 |
| --- | --- | --- | --- |
| [primary] | ... | 具体数字 | 30/60/90 天 |
| [secondary] | ... | ... | ... |
| [health] | ... | ... | ... |

度量来源：brief.design_criteria.quantitative + brief.business_goal

• Anti-metrics（反指标）：这是 SparkSkillsHub PRD 的特色之一。明确不优化什么——例如"通知打开率"虽然好看但优化它会破坏信任。每个 PRD 至少列 1 个 anti-metric。
• 关键假设：来自 frame.critical_assumption——一句话写出"如果错了就意味做错产品"的假设。

Section 5 — Value Proposition

对主用户：

"[persona name] 终于可以 [JTBD] 而不必 [当前阻力]，因为 [本产品做了什么不一样的事]。"

对 buyer（如不同于 user）：相同模板。

竞争差异化：2-3 句。要具体，"更好的 UX" 不算差异化。来自 frame.competitive_landscape——明确对手做对了什么、留下什么空白、本产品填的是哪个空白。

Section 6 — Solution & Feature Scope（最重要章节）

这一段是 SparkSkillsHub PRD 跟传统 PM PRD 最大的不同——它显式包含设计触点和已生成的设计资产引用，让 coding agent 直接消费。

对 stories 中每个 Story（按 priority 降序），生成以下结构：

### [Story 标题]

**Persona**：[story.persona]
**Job**：[story.scenario] → [JTBD 动机]
**优先级**：P0 / P1 / P2
**关键假设标记**：⭐（仅当 critical_assumption=true）

**功能描述**（2-3 句，从用户视角，平实语言）：
[基于 story.scenario 和 story 主体生成]

**In Scope（这版要做的）**：
- [基于 story.acceptance_criteria 转译]
- [...]

**Out of Scope（这版故意不做的）**：
- [基于 brief.out_of_scope + story.priority < p0 的部分]

**验收标准（Given / When / Then）**：
- Given [情境]，When [动作]，Then [可观察结果]
- Given [情境]，When [动作]，Then [可观察结果]
- 边缘情况：[X 出错时怎么办]
- 空状态：[没数据时用户看到什么]

**设计触点**（来自 story.design_touchpoints）：
- 涉及屏：[...]
- 涉及组件：[...]
- 涉及状态：[...]

**关联 Sitemap 页面**（来自 sitemap.pages）：
- [page.id]: [page.route] — [page.label]

**已生成的设计资产**（来自 flow-web.output_files / flow-mobile.output_files）：
- `src/app/(retro)/new/page.tsx` — Three Questions 屏
- `src/components/retro/WeekStreak.tsx` — 连续打卡组件
（如果上游有 flow 输出则列出，没有则标注"待生成"）

**待澄清问题**：
- [story 阶段未解决的决策项]

关键规则：

• 每个 Story 一节，按 priority 降序（P0 在前）
• 没有上游 flow 时"已生成的设计资产"标注为"待生成"，提示工程师走 vibe coding 流程
• 已生成的设计资产必须列具体文件路径，不要写"在 src/app 下"这种模糊描述

最后单独列一个"未列入本版的 Stories"小节，列 P2 或低优先级 Story 的标题，备 Phase 2 引用。

Section 7 — Constraints & Risks

• 技术约束：来自 brief.constraints。例如"4 周交付"、"Web 优先"、"必须用 SparkDesign"
• 设计约束：UX pattern / 无障碍要求等不可妥协项。来自 brief.design_criteria.qualitative
• 数据 & 隐私：本 PRD 涉及哪些个人数据？合规考虑（GDPR / CCPA / 国内法规）？
• 关键风险表：

| 风险 | 可能性 | 影响 | 缓解措施 |
| --- | --- | --- | --- |
| [关键假设错] | High | High | [最便宜的测试，来自 frame.critical_assumption + 关联条件] |
| [技术依赖失败] | M | M | [fallback 方案] |
| [用户不接受] | M | H | [灰度 / 测试方案] |

特别引用：如果上游有 check.findings，把其中的 blocker / major 项列入 risks 表（"已识别但未修复的设计问题"）。

Section 8 — Release Approach

• 推荐顺序：哪个 Story 先发，为什么？优先发关键假设测试 Story（来自 frame.critical_assumption + stories.critical_assumption=true 的 Story）
• MVP 定义：最小 Story 集合，能交付足够价值且能验证核心假设。显式列 Story 标题
• Phase 2（如适用）：故意延后到第二版的内容，为什么
• 上线考虑：
  • 上线前需要通知谁？（stakeholders / 客服 / 法务）
  • 是否 soft launch / beta 降风险？
  • 上线后头 2 周监测什么？

Step 3 — 自检与 thin_sections 标注

PRD 生成完后，对每段做"完整度自检"：

任何一段评级"薄"的，记入 thin_sections，在 PRD 末尾标注。

Step 4 — 输出（保存文件 + 双通道 Context）

4.1 保存 Markdown PRD

文件路径：spark-output/prd/[direction-slug].md

direction-slug 来源（按优先级）：

1. frame.lean_direction 的 slug 化
2. brief.project_name 的 slug 化
3. 用户提供

完整 PRD Markdown 文件结构：

# PRD — [项目名] / [direction]

- **生成时间**：[ISO8601]
- **数据源**：[brief / stories / sitemap / flow-web / ...] [N] 个上游 Skill
- **完整度**：strong / moderate / thin

[Section 1 - Summary]

---

## Background & Problem

[Section 2]

---

## Personas

[Section 3]

---

## Goals & Success Metrics

[Section 4]

---

## Value Proposition

[Section 5]

---

## Solution & Feature Scope

[Section 6 — 每个 Story 一段]

---

## Constraints & Risks

[Section 7]

---

## Release Approach

[Section 8]

---

> ⚠️ **薄弱章节提示**（如有）：
> [thin_sections 中每条说明缺什么、建议怎么补]

4.2 双通道 Context 输出

按 chain-protocol.md 第 2.1 节执行。

Step 1 — 写盘到 spark-output/context/prd.json（必做，主持久化通道；仅含元数据 + 章节摘要，不含 PRD 全文——PRD 全文在 spark-output/prd/[slug].md）。写入以下完整 JSON：

{
  "skill": "prd",
  "generated_at": "<ISO8601>",
  "project_name": "...",
  "direction": "...",
  "prd_file": "spark-output/prd/[direction-slug].md",
  "sections_summary": {
    "summary": "<Section 1 一句话>",
    "primary_persona": "<persona name>",
    "product_goal": "<one sentence>",
    "success_metrics": [
      { "metric": "...", "target": "...", "timeframe": "..." }
    ],
    "feature_count": 0,
    "in_scope_features": ["..."],
    "out_of_scope_features": ["..."],
    "critical_assumption": "...",
    "mvp_stories": ["..."]
  },
  "source_skills": {
    "brief": true,
    "stories": true,
    "sitemap": false,
    "flow_web": true,
    "flow_mobile": false,
    "frame": true,
    "scope": false,
    "check": false
  },
  "thin_sections": ["release_approach"]
}

Step 2 — chat 输出紧凑 marker（必做，⛔ 不要在 chat 内重复输出 Step 1 的完整 JSON）：

<!-- spark-context:prd ref="spark-output/context/prd.json" -->
PRD 已保存：project=[project_name]，direction=[direction]，[N] 个 Story / MVP=[mvp_stories]，prd_file=spark-output/prd/[slug].md
<!-- /spark-context:prd -->

降级 fallback：若 Step 1 写盘失败（chat-only 平台），输出完整 JSON marker（无 ref 属性，marker 之间放裸 JSON）作为唯一持久化通道。

Handoff 提示（必输出）

协议：按 _shared/next-skill.md 三层结构模板输出；前 5 候选由 _shared/skill-graph.json 的依赖图算法实时算（done ⊆ ready，按 next_hint.preferred → alternatives → 同阶段 → anchor → fan-out 排序），优先建议从 _shared/skill-graph.json#skills[id="prd"].next_hint 读取。

首行模板：✅ 写PRD 已完成，8 段工程交付文档 + 先发 Story 推荐已就绪，已保存到 spark-output/prd/[slug].md。

本 Skill 的 next_hint（来自 skill-graph.json，不可在此 SKILL.md 内硬编码覆盖）：

• preferred：/extract
• 优先理由：PRD 已交付工程，进 Extract 把设计 token 抽出来给工程实现侧消费，让代码与设计稿对齐。
• alternatives：/qa (等工程实现后做还原度验收) · /metric (PRD Section 4 想用 Metric 蓝图替代 Brief 简版)
• emoji：📄

红线：

• ❌ 禁止在本段硬编码候选清单（如「进入 Stories / Journey / Sitemap」）——所有候选必须由算法实时生成
• ❌ 禁止按「文档类 / 视觉类 / 决策类」再分类候选（v0.5.5 起，分类已折叠进 next_hint.alternatives）
• ❌ 禁止与「更新链路面板」段合并——两段必须各自独立成段，中间空一行
• ❌ 禁止漏第 2 行候选清单——即使候选只有 1 个、或为空（终端节点）也要写出来

实操注意事项

不要做的事

• ❌ 不要再做研究：PRD 生成阶段，所有用户研究 / 竞品分析 / 商业判断都应该已经在上游 Skill 完成。PRD 是整合不是创造
• ❌ 不要凭空补字段：上游缺什么就标 thin，不要为了"PRD 看起来完整"自己编
• ❌ 不要写 PM 视角的论证：PRD 不需要"为什么我们应该做"的长篇论证，那是 Frame / Brief 的事
• ❌ 不要遗漏 design_touchpoints：Solution 章节的核心差异化就是设计触点，漏了 PRD 就退化为普通 PM PRD

最适合的使用场景

• 独立设计师：自己设计完，没 PM，要交付工程
• AI 原生设计师：vibe coding 后把设计产出转 PRD 给 coding agent 系统化实现
• 团队设计师（少见）：补充 PM 没写到的设计相关 PRD section（一般直接合并到 PM 的 PRD）

非最佳场景

• 项目还在方向探索阶段（用 Frame）
• PRD 已存在且要解读（用 Scope）
• 要评估设计稿完整度（用 Check）

已知限制

• PRD 质量上限取决于上游 context 的完整度，"垃圾进垃圾出"
• 不能替工程师做技术选型 / 架构决策
• 不能替 PM 做商业模型论证（如 unit economics / go-to-market）
• 大型多 Squad 项目可能需要拆多个 PRD（按 Squad 拆 stories 集合分别生成）

与兄弟 Skill / PM 套件的边界（v0.4.0 补充）

PRD 不可替代性：设计师视角的工程交付 PRD，重点是「设计资产路径（.tsx / Figma）+ 交互细节 + 验收标准 + 埋点字段」，与 PM 套件 PRD 互补——PM 写「为什么做 + 业务价值」，设计师 PRD 写「设计怎么落 + 工程怎么做」。

质量标准

1. 8 段结构完整：1 概要 / 2 用户故事 / 3 信息架构 / 4 页面 Flow / 5 交互细节 / 6 设计资产 + 埋点 / 7 验收标准 / 8 异常态——8 段一段不少
2. Section 6 必含 .tsx 路径：设计资产段必须含具体代码文件路径 + Figma 链接，不能只说「见设计稿」
3. 上游 chain 强制消费：必须读取 brief + frame + scope + stories + sitemap + journey + flow-web + flow-mobile + check 九个上游（缺则在文档头部标 ⚠️）
4. 验收标准 ≥ stories 数量 × 2：每个 story 至少对应 2 条工程可验收标准（功能 / 视觉 / 交互）
5. 埋点字段对齐 Metric：Section 6 埋点列表必须与 Metric.events 一一对应，event_name / 字段一致
6. 行数 ≥ 500：完整 PRD（含 8 段 + 表格 + 资产路径）应 ≥ 500 行，过短即视为漏内容

红线规则

1. 不替代 PM PRD：设计师 PRD 不写「为什么做这个产品 / 商业价值 / 优先级排序」——那是 PM 套件的范围
2. 不省略异常态：Section 8 必须覆盖来自 Edge 的异常态清单，不能只写 happy path——红线场景：上线后客服爆「错误页没设计」
3. 不脱离上游 stories / brief：PRD 出现的新功能 / 新交互必须能追溯到 stories 或 brief，凭空加内容 = 红线