ewancy requirement-prd-writer / 需求说明文档编写
调用原则
只在用户目标是“写或改需求说明/PRD”时使用本 Skill。所有正式 PRD 必须先完成知识库门禁：找到并只读对应需求知识库，或获得用户明确确认“本次不需要知识库”；随后必须先向用户输出“待确认问题”并等待用户确认问题口径，再输出“需求编写方案”并等待确认，确认后才生成或更新正式 PRD。
本 Skill 不得在 PRD 编写流程中自动创建、覆盖或更新正式知识库。只有用户明确说“建立知识库 / 创建知识库 / 更新知识库 / 同步知识库 / 沉淀到知识库”等写入意图时，才允许调用 $requirement-kb-creator 或 $requirement-kb-updater 落盘正式知识库；否则只能输出知识库缺口、禅道检索摘要、待更新草稿或本轮规则摘要。
本 Skill 不负责制作 HTML 原型；如果用户要求原型，应在 PRD 完成后使用 $html-interactive-prototype。
方案确认规则
正式需求说明必须先确认问题口径，再确认方案，不要在用户首次提出“写需求/生成 PRD”后直接落盘 PRD。
中文说明：问题确认是为了先校准不确定口径，方案确认是为了再校准需求范围、业务假设、前后端拆分和章节组织，避免 AI 直接把不确定内容写成正式规则。知识库门禁仍然优先执行，但在用户未明确要求写入知识库前只能只读知识库或整理草稿，不能先完成正式知识库沉淀；正式 PRD 文件必须等用户确认问题口径和方案后再生成。
- 完成知识库门禁和输入梳理后，先输出“待确认问题”，等待用户明确确认问题口径；用户可以逐条回答，也可以回复“按默认处理”。
- 待确认问题应聚焦会影响需求口径的内容，包含问题、影响、建议默认处理方式；不要把不影响需求落文的闲聊问题列入阻断项。
- 用户确认问题口径后，再输出一份简短的“需求编写方案”，等待用户明确回复确认、继续、按这个写、没问题等同义表达。
- 用户未确认问题口径和方案前，不要创建、覆盖或更新正式
...需求说明.md；也不要输出完整正式 PRD 正文。 - 方案应包含：
- 需求名称：拟生成的 PRD 标题。
- 关联知识库：主知识库、次要知识库，或用户确认不需要知识库的口径。
- 本次目标：1-3 条核心目标。
- 拟写章节：说明是否沿用精简默认章节；默认顺序为
需求概述、功能改动、规则与边界、页面截图、待确认问题、版本记录，默认不写改动范围、验收标准、数据与接口。 - 关键规则假设：基于用户输入和知识库推导出的规则，标明“已确认/待确认”。
- 待确认问题处理结果：列出用户已确认的关键问题口径；如仍有非阻断问题，说明建议默认处理方式。
- 输出路径：拟生成文件路径。
- 如果用户在同一轮明确说“无需确认，直接生成”“按默认方案直接写”“问题和方案都按默认处理”等，仍需完成知识库门禁，但可以跳过问题确认和方案等待，直接生成 PRD，并在最终回复说明用户已授权跳过确认。
- 如果用户只要求“先给我方案/大纲/思路”，只输出方案，不生成 PRD。
- 如果用户对待确认问题或方案提出修改，先更新本轮问题口径或方案；只有用户明确要求“更新/同步知识库”时，才把修改写入正式知识库。
知识库前置规则
需求编写必须基于并关联知识库。没有知识库时，不要直接写 PRD。
中文说明：知识库是需求事实来源，用来沉淀历史规则、业务边界和已确认口径。PRD 只能基于用户明确输入、已有 PRD、知识库或已抽取的禅道材料编写，不能跳过知识库直接生成。
- 写 PRD 前先识别功能点，并在当前工作区查找
功能点/<功能点名称>/<功能点名称>需求知识库.md或用户指定的...需求知识库.md。 - 如果存在多个相关功能点，PRD 必须在“关联知识库”中列出主功能点和次要功能点知识库。
- 读取知识库时检查
需求来源/关联任务/记录是否包含禅道历史检索记录；如果知识库没有记录“已查禅道历史需求/未命中/复用记录/检索失败原因”，不要直接改写知识库，应输出“知识库来源缺口/建议补查项”，并在 PRD 方案中标明该风险。 - 如果找不到对应知识库，不能自动新建正式知识库；先询问用户是否需要建立知识库，或取得用户确认本次不需要知识库。
- 知识库补齐流程：
- 只有用户明确要求“建立/创建/更新/同步知识库”时，才使用
$requirement-kb-creator或$requirement-kb-updater落盘正式知识库。 - 功能点名称清晰但用户未要求写入知识库时，只能整理“知识库待补草稿/本轮规则摘要/禅道检索摘要”，不得写入正式
...需求知识库.md。 - 已有知识库但缺少本次规则、禅道历史检索记录或来源摘要时，只提示建议更新知识库；除非用户明确同意更新，否则继续保持只读。
- 功能点归属不清、候选知识库过多、用户明确不想建库，或创建知识库会引入不确定历史口径时，先向用户确认。
- 只有用户明确要求“建立/创建/更新/同步知识库”时，才使用
- 如果用户确认不需要知识库，则按“独立新功能”继续编写正式 PRD；PRD 的“关联知识库”写明
无，用户确认本次按独立新功能处理，并在规则与边界中说明后续如该功能持续迭代再补充知识库沉淀。
推荐口令
$requirement-prd-writer 基于 xxx需求知识库.md 生成新需求说明需求文档：根据这些变更点写一份 PRD基于知识库补充新需求说明，不要写数据与接口章节帮我设计一个需求：xxxx
工作流程
确认并读取知识库
- 先根据需求标题、用户描述和目录结构识别涉及功能点。
- 查找并读取相关
...需求知识库.md；没有知识库时询问用户是否建立知识库，或取得用户明确豁免。 - 检查知识库是否有可追溯的禅道历史检索记录；如果没有且用户未明确要求跳过禅道，只输出来源缺口和建议补查项，不得自动写入正式知识库。
- 确认已有知识库、用户明确要求并已通过知识库技能建立/更新知识库，或用户确认本次不需要知识库并按独立新功能处理后，才进入 PRD 编写。
- 门禁自检：如果准备落盘 PRD 时仍没有“主知识库”或“用户确认不需要知识库”的依据，立即停止写 PRD，先补齐知识库。
读取输入
- 优先读取用户指定的知识库或已有需求文档。
- 如果用户直接给变更点，先识别背景、目标、范围、规则、验收口径。
- 将用户补充规则与知识库规则对齐；冲突内容写入待确认或本轮规则摘要。只有用户明确要求“更新/同步知识库”时，才按用户最新明确口径更新正式知识库。
输出待确认问题并等待确认
- 按“方案确认规则”先输出待确认问题表，包含问题、影响、建议默认处理方式。
- 明确说明“确认问题口径后，我再输出需求编写方案”。
- 在用户确认问题口径前停止，不要输出需求编写方案，不要落盘正式 PRD。
- 用户确认后再继续执行方案步骤；如果用户补充新口径，先同步到本轮规则摘要。只有用户明确要求“更新/同步知识库”时，才写入正式知识库。
输出方案并等待确认
- 按“方案确认规则”输出需求编写方案。
- 明确说明“确认后我再生成正式需求说明”。
- 在用户确认前停止，不要落盘正式 PRD。
- 用户确认后再继续执行后续步骤；如果用户要求调整方案，先修改方案或本轮规则摘要，再等待确认；不得顺手更新正式知识库。
组织结构
- 参考
references/prd-template.md。 - 默认章节顺序：需求概述、功能改动、规则与边界、页面截图、待确认问题、版本记录。
页面截图默认放在规则与边界后面；只有用户明确要求截图前置时才调整位置。- 默认不要写
改动范围、验收标准、数据与接口/接口与数据字段，不要写技术实现字段、接口名、数据库字段或代码变量，除非用户明确要求技术方案。 功能改动合并前端和后端描述，按功能点、页面或配置入口组织，用产品/业务语言写页面、配置、交互、保存和生效口径，避免重复和技术实现细节。规则与边界只写跨页面、权限优先级、兼容、不处理范围、一致性、风险等全局规则；不要重复功能改动已写清的页面字段和交互步骤。需求概述中必须包含“关联知识库”，列出本次 PRD 使用的知识库名称；如果用户确认不需要知识库，写明无，用户确认本次按独立新功能处理。
- 参考
写需求详情
- 优先精简：需求概述控制在 3-6 条，功能点说明只保留可测试、可配置、用户可感知的规则。
- 同一规则只落一个主位置：入口/字段/交互写在
功能改动；权限优先级/兼容/不处理范围写在规则与边界；截图说明只描述截图对应页面和改动位置。 - 对用户明确要求的规则必须逐条落文档，但不要在概述、功能改动、规则与边界、截图说明中反复表达同一句规则。
- 对不确定内容写入风险/待确认，不要写成确定规则。
- 表格用于表达待确认问题、版本记录、截图清单等结构化信息；能用短列表表达的内容不要强行表格化。
- 版本记录默认只保留关键版本和当前版本，避免保留大量已被推翻的中间口径；如需完整审计记录，保留在知识库或禅道动态中。
校验
- 章节编号连续。
- 已关联至少一个需求知识库；如果没有知识库，必须能追溯到用户确认“不需要知识库，按独立新功能处理”的口径。该项是阻断项，不满足时不得交付正式 PRD；不得通过未授权新建/更新知识库来绕过。
- 已获得用户对待确认问题口径和方案的明确确认，或用户已明确授权跳过问题确认和方案确认；该项是阻断项，不满足时不得生成或更新正式 PRD。
- 不包含改动范围、验收标准、接口章节、技术实现字段、数据库字段或代码变量，除非用户明确要求。
- 用户给出的每条需求都能在文档中找到对应描述；同一规则没有不必要的重复表达。
- 本地文档不能包含密码、token、cookie。
页面截图位于规则与边界后面，除非用户明确要求其他位置。- 如果这份 PRD 准备提交到禅道，正文中的原型/图片/流程图不得保留
/Users/...、/home/...、C:\...、file://...、localhost、127.0.0.1等本地路径或临时地址；默认通过.md附件承载本地截图，用户明确要求内嵌图片时再上传图片并使用禅道webPath直连地址。
原型与图片引用规则
- 本地交付：可以在最终回复中列出绝对路径，方便用户在当前电脑打开。
- PRD 正文：如果后续要提交禅道，默认写
需求文档：查看禅道附件 <需求说明>.md，不要默认引用原型 ZIP。 - 页面截图：本地评审版可用 Markdown 图片；提交禅道时默认不上传截图附件。只有用户明确要求图片显示在禅道正文时，才上传图片并转成
<img src="https://<禅道域名><webPath>" style="max-width:100%;" />；此时禅道附件列表会出现图片附件；不要用<a><img /></a>包图。若需要查看大图，提交流程应在图片下方增加mouse=left禅道预览链接，避免点击图片被禅道改写为下载。 - 页面截图章节默认放在
规则与边界后面，固定为“页面 / 截图 / 说明”三列；说明只写页面用途和本次改动位置，不重复统计口径、权限优先级等正文规则。 - 多个原型/流程图/截图：默认保留在
.md需求文档中，不作为禅道独立附件；用户明确要求上传时再逐项处理。 - 不要把本机绝对路径、
file://、本地 HTTP 服务地址写进会同步到禅道的 PRD 正文；如果无法拿到可访问图片地址，则正文写“查看需求文档附件”。 - 如果已有 PRD 含本地路径且用户要求提交/变更禅道，先替换为“查看需求文档附件”后再提交。
- 如果用户已明确计划提交禅道，默认只确保
.md需求文档文件名与正文引用一致；图片/原型附件名只有在用户明确要求上传时才需要逐项匹配。
输出约定
推荐文件名：<需求名>需求说明.md 或 <需求名>优化需求说明.md
问题确认阶段：只输出待确认问题、影响和建议默认处理方式；不要输出需求编写方案或正式 PRD 路径作为已完成结果。
方案阶段：只输出需求编写方案、已确认问题口径和拟输出路径；不要输出正式 PRD 路径作为已完成结果。
生成阶段：最终回复列出文档路径和覆盖的关键变更点。
禅道提交注意：当前禅道会清洗 base64 图片，正文需要显示图片时无法做到“无图片附件”。如用户要求附件只保留
.md，则禅道正文不能直接显示截图，只能在.md文档内查看。禅道正文截图建议使用固定宽度等比例
<img width="520">缩略图；不要使用背景图裁切方案。