PRD Writer
这个 Skill 用来把零散业务信息整理成符合用户既有文档风格的中文 PRD。目标不是学习某个具体业务领域，而是复用样例 PRD 的写作格式、拆解粒度和表格表达方式，让新文档看起来像同一个人/同一套团队规范写出来的。
这个目录里有什么
SKILL.md：主说明文件。告诉 Codex 什么时候使用这个 Skill，以及写 PRD 的工作方法。references/prd-template.md：从两个样例 PRD 抽象出的文档模板。需要从 0 起草 PRD 时读取。references/prd-quality-checklist.md：按样例格式整理出的质量检查清单。需要补全、评审、润色已有 PRD 时读取。agents/openai.yaml：界面展示信息。用于 Skill 列表里的名称、简介和默认提示词。
后续怎么使用
把 prd-writer 放到 Codex 可发现的 skills 目录后，可以这样提需求：
使用 $prd-writer，根据这份会议纪要帮我写一版 PRD。
使用 $prd-writer，参考这个旧 PRD 的写法，把下面的新需求整理成 PRD。
使用 $prd-writer，检查这份 PRD 有没有缺字段、按钮逻辑、权限、状态流转和待确认项。
如果 Skill 还没有放到全局 skills 目录，也可以直接说：
参考 D:\Desktop\PRD.skill\prd-writer 这个 Skill，帮我写一版 PRD。
工作流程
- 先读取用户提供的全部资料。遇到
.docx时同时抽取段落和表格，因为很多需求细节藏在表格里。 - 先识别业务域、用户角色、平台范围、核心对象、主流程，再开始写正文。
- 用户要“新写/起草 PRD”时，读取
references/prd-template.md。 - 用户要“优化/补全/评审 PRD”时，读取
references/prd-quality-checklist.md。 - 已知事实必须保留原意；缺失的信息标为
待确认，不要擅自编业务规则。 - 页面类需求先保留
原型文件/页面现有截图/UI 占位，再写页面用途、字段、按钮、列表、查询条件、状态、权限、校验和统计口径。 - 字段、按钮、列表、查询条件、状态、权限、校验、统计口径优先用表格表达，保持样例 PRD 的“表格化拆解”风格。
- 聚焦 PRD 写作，不输出代码、工程结构或具体开发实现方案；如需技术约束，只写到接口、数据来源、兼容范围、验收口径等 PRD 必要层面。
- 用中文业务语言写，但逻辑要精确到研发和测试可以执行。
输出风格
- 使用清晰的编号标题，例如
1. 业务背景、2. 痛点说明、6. 需求描述。 - 大需求按“模块 > 页面/流程 > 字段/按钮/规则”拆解。
- 每个模块尽量包含：功能描述、业务流程、应用场景、原型文件/页面现有截图、页面与功能拆解、状态流转、校验规则、数据权限、数据来源、看板口径、验收标准。
- PC 网页和小程序行为不一致时，分开描述。
- 看板指标必须写清楚分子、分母、时间范围、统计维度、权限范围、导出规则和边界情况。
- 状态流转必须写清楚状态名称、进入条件、可执行操作、下一状态。
从样例抽象出的格式规范
两个样例 PRD 体现出两种常用结构。写新 PRD 时按需求复杂度选择其一，或组合使用。
结构 A：完整业务 PRD
适合较大的项目、跨角色流程、需要说明背景和收益的需求。
1. 业务背景2. 痛点说明3. 期望上线时间4. 业务需求方5. 预期收益 ROI6. 需求描述6.x 模块名称6.x.1 业务流程6.x.2 PRD需求说明- 页面入口、原型文件/页面现有截图、新增/列表/看板/明细等页面拆解
- 人员/主数据/权限等配套方案
- 待确认事项
结构 B：功能模块 PRD
适合单个模块或功能点，强调页面字段、按钮和业务规则。
功能描述流程图应用场景功能拆解页面原型/UI 截图页面结构设计数据来源说明按钮查询条件列表字段唯一性校验排序数据权限
表格表达规则
- 应用场景使用
场景 / 对象 / 场景描述。 - 原型/UI 截图区使用
原型编号 / 页面名称 / 端类型 / 原型位置或截图占位 / 说明，先放图或占位，再写页面规则。 - 字段说明使用
列表名称或区域 / 字段名 / 字段类型 / 是否必填 / 字段含义。 - 按钮说明使用
所属页面 / 按钮名称 / 显示逻辑 / 按钮逻辑（业务控制逻辑/校验逻辑）。 - 查询条件使用
列表字段 / 逻辑说明。 - 列表页字段使用
列表字段 / 逻辑说明。 - 看板或统计类需求必须写清楚计算口径；如果口径来自 Excel，标注“具体计算口径见 Excel”并补充已知规则。
- 规则类信息放在模块末尾，例如：唯一性校验、取值优先级、初始化、PC 网页/小程序互通、排序、数据权限。
什么时候要追问
只有当答案会明显影响 PRD 结构或业务规则时才追问。否则先合理假设，并在文档里标 待确认。
优先追问这些问题：
- 目标平台是 PC 网页、小程序，还是两端都要做。
- 具体用户角色和数据权限边界。
- 审核、稽核、激励是否在本期范围。
- 上线时间、分期范围和本期不做内容。
- 现有系统、来源数据和接口/同步约束。
完稿前检查
交付前检查 PRD 是否包含：
- 谁在什么场景下使用，解决什么业务问题。
- 每个关键页面/列表/表单是否有字段、按钮、显示和置灰规则。
- 必填项、候选范围、默认值、校验提示是否明确。
- 状态流转和操作权限是否完整。
- 数据权限、排序、导入、导出是否明确。
- 看板指标是否有公式和统计维度。
- 不确定事项是否统一放在
待确认事项。
