Prd Writing

PRD Writing Skill

产出一份结构完整、可评审的 PRD。skill 本体不含任何产品特有信息—— 产品差异（覆盖端、知识库、输出格式、产品特性）全部来自产品上下文文件，见同目录 PRODUCT-CONTEXT.md。

阶段 0：产品上下文（先读，缺了才问）

按本 skill 同目录的 PRODUCT-CONTEXT.md 协议定位 product.md：

1. cwd 下有 .prd/product.md → 用它（repo 场景）
2. 否则在 PM 工作区（默认 ~/Documents/PM，可在首次访谈中改）下按产品名匹配 <产品名>/product.md
3. 都没有 → 这是该产品首次使用，做一轮明确询问（AskUserQuestion，一次问完不反复）：
   • 产品名 + 一句话定位
   • 覆盖哪些端（自由填写，不预设枚举）
   • 有没有产品知识库/资料库？在哪（路径或 URL）？没有就记"无"
   • PRD 默认输出格式：markdown 还是 html
   • 产品关键特性假设（离线优先？实时协作？单机工具？——决定异常场景章节写什么）
   • 产品资料与产出放哪（默认 PM 工作区 ~/Documents/PM） 然后把答案写入工作区的 <产品名>/product.md，之后所有 PM 类 skill 共享，不再问。

如果 requirement-eval 或 tracking-plan 已在这个产品上跑过访谈，product.md 已存在——直接读， 只补问缺失字段，绝不重复已回答的问题。

另外每次询问本单 PRD 的信息：需求名、目标版本、是新增能力还是梳理现有能力、有无交互稿链接。

阶段 1：一页纸骨架（先确认再展开——万字 PRD 的解药）

不许直接开写全文。先产出一页纸给用户确认：

• 需求背景一句话 + 核心目标（编号列，末尾「一句话说清楚需求」）
• 章节骨架（列到二级标题）
• 分档建议，三档字数是硬预算不是参考值：

用户确认骨架和档位后才进阶段 2。展开时超预算 = 回头砍字，优先砍成段的描述，改表格。

阶段 2：正文展开

核心原则：

1. 能表格化就表格化——涉及面、支持端、菜单项、埋点事件全用表；同一信息不许在两处成段重复。
2. 跨端先勾版本线——覆盖端矩阵表（端的枚举来自 product.md），✅/⬜ 勾选（避免 🗹/🞎，多数字体渲染成方框）。
3. 危险/异常显式写——删除类操作单独标样式文案；异常场景单列一节，写什么由 product.md 的产品特性决定（离线优先的写离线/弱网/冲突，在线服务的写超时/降级/限流）。
4. 区分「新增能力」还是「梳理现有能力」——写进背景，避免开发误判工作量。
5. 有产品知识库就先查——product.md 里登记了知识库的，写背景/竞品/现状前先去查，别凭空编。

章节顺序（Lite 档可裁剪）：

1. frontmatter（title/author/type: PRD）+ 版本记录表
2. 版本线矩阵表 + 范围说明
3. 涉及面表（模块｜是否涉及｜说明）
4. 协作同学、相关资源、名词解释（Lite 档可省）
5. 需求背景 → 用户场景（编号列：谁+什么情况+做什么）→ 核心目标
6. 功能概述（逻辑原则 + 入口表）→ 需求详情（表格化）
7. 异常场景处理
8. Complex 档：分端专章，每端列任务清单

阶段 2.5：配图

纯文字墙不可评审。以下位置默认配图，不等用户要求：

• 主流程 → flowchart
• 有状态流转的功能 → stateDiagram
• 多角色/多端交互 → sequenceDiagram

实现方式按输出格式。markdown PRD 的常见导入目标（在线文档类产品）既不渲染 mermaid fence、 也不渲染 ![]() 图片链接和 <details> 标签——唯一在所有环境稳定的是等宽代码块，所以：

• markdown 产出（默认） → 徒手 ASCII，放 ```text fence，画法规格：
  1. 结构字符只用纯 ASCII（| v + - = \ /）——box-drawing（─│┌└├▼）是 East Asian Ambiguous 宽度，字体不同宽度不同，本身就是塌陷源；纯 ASCII 宽度恒为 1，永不飘
  2. 需垂直对齐的字符尽量放在该行第一个中文之前（结构在左、文本在右）；不画封闭框（不写右边线）
  3. 双列并排流默认不用（读者字体 CJK 非严格 2:1 时右列与轨道脱节）；product.md 里记录过 "导入环境实测双列 OK"的产品可以用——视觉确实更好
  4. 居中对称、条幅、行尾装饰性右列（事件名/数值）允许——坏字体下只偏移不散架
  5. 行宽 ≤ 80 显示列（中文算 2）
  6. 漏斗：四列布局——事件名（ASCII，定宽左列）｜bar（在定宽字段内居中）｜百分比（右对齐）｜ 中文标签（行尾）。中文只出现在行尾，前三列纯 ASCII，任何字体下都稳；bar 居中给出漏斗对称感：
     • bar 字段总宽 32 格；bar 宽 = 比例 × 32 取偶数（左右 padding 才完全相等），最小 4 格
     • bar 字符用 ▇；读者环境里 %/标签列上下歪了（说明该字体 ▇ 非 1 宽）就换纯 ASCII #

     fav_panel_show   ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇  100%  面板唤起
     fav_add_click           ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇          56%  收藏操作
     fav_tab_show                ▇▇▇▇▇▇▇▇▇▇               31%  收藏Tab曝光
     fav_item_paste                 ▇▇▇▇                  12%  收藏条目粘贴
     

     普通占比对比（非漏斗）用左对齐条形图（termgraph 范式，比长短需要公共基线），中文标签同样放行尾 写完跑本 skill 的校验器：python3 <本 skill 目录>/scripts/ascii_guard.py check <文件.md>， 不过就按报错改、改完重跑，绿了这张图才算存在。

• product.md 里「PRD 配图方式」明确为 mermaid fence（读者环境确认渲染 mermaid：Obsidian/GitHub 等）→ 用 ```mermaid fence
• html 产出 → 调 diagram-design 产 inline SVG（不用 mermaid，观感和可控性都更好）；简单小图可手写 inline SVG

阶段 3：埋点与成功指标 —— 调用 tracking-plan skill

只要功能会产生新的用户行为路径，就必须做这一步；纯内部梳理类需求可只写成功指标。 读 tracking-plan skill 的 SKILL.md（它同样读 product.md 拿埋点体系配置）， 产出「数据埋点与成功指标」章节附到 PRD 末尾。

阶段 4：落盘与自检

产出写到产品文件夹（product.md 所在目录）的 prd/<需求名>.md|.html（repo 场景写 cwd 的 .prd/）。

• 骨架和档位经过用户确认了？正文没超预算？
• 版本线矩阵表勾了？核心目标后有「一句话说清楚需求」？
• 危险操作、异常场景单独写了？能表格化的都表格化了？
• 主流程有图？ascii_guard.py check 对最终 md 跑过且是绿的？
• 带了「数据埋点与成功指标」章节（非纯梳理需求）？