用途：把产品意图转成可评审、可交接、可持续维护的需求文档。PRD 是本次功能的决策记录，不重复抄写已确认的全局产品规则，也不是逐像素的 UI 实现说明。
模式：完整模式用于首版产品、重大新模块或需重新对齐问题、用户、策略和指标的方案；无任何可复用体验基线且涉及定位或商业模式变化时同样适用。增量模式为默认，用于已在迭代产品新增或调整功能，写清本次变化及其与体验基线的关系。小型 bug、文案修正或已完全明确的工程任务不需要完整 PRD，走仓库既有 issue/task 流程。
开始前：确定短横线格式的功能名 <feature-name>，目标路径 docs/prd/<feature-name>/prd.md；读取仓库约定、相关现有 PRD、受影响页面和相关代码。已有 PRD 时先征求用户选择更新、另建功能目录或保留原文。查找 docs/product/<project-name>/，读取 product-context.md、相关端的 ux-foundations.md 与 patterns.md，以及 component-promotion-log.md（若存在）；多产品或无法判断目录时请用户指定，不得凭空选择基线。无基线时继续写功能 PRD 但标记“无体验基线”。事实标来源，推断标 [INFERRED]，无法确认的列入待决问题。
增量 PRD 必须明确四类内容：复用基线（本次沿用的导航、页面模式、文案、状态或组件规则）、功能局部（只为本次功能存在的流程、字段、权限和异常状态）、候选晋升（可能将来复用但尚未成为产品规则的模式）、有意偏离（与基线不同之处、原因、影响端和回写判断）。未经确认的单次模式只能标为候选；模式已被两个已确认功能采用或产品明确确认时，应提示用 product-experience-foundation 更新 patterns.md 与晋升记录；PRD 与基线冲突时记录偏离，不能静默覆盖。
输出结构以 template.md 为基础，增量模式必须保留 0、1、2、5、7、8、9、10 节，3、4、6 节可精简或省略；完整模式填写所有适用章节。需求与验收按用户可验证行为组织，写清角色、触发条件、主流程、状态变化、权限、异常和验收结果。原型、设计规格、竞品证据放在同一功能目录并从 PRD 链接。
协作与后续：完成草案后用 grill-with-prd 审查范围、矛盾、边界、异常和未决问题并回写；需要外部视觉证据用 web-design-extractor，独立高保真评审原型用 design-spec-prototyper，贴合项目现状的可点击高保真原型用 pm-frontend-prototype。交付时说明 PRD 路径、模式、读取的基线、复用规则、候选/偏离、未决问题与下一步评审动作。
限制与常见问题：避免把 PRD 写成全产品说明书、把设计细节当需求、缺少非范围、假装基线已确认、隐藏不确定性。交付前检查路径正确、模式与理由、基线读取情况、四类内容、范围与非范围、角色状态权限异常与验收、来源标记或开放问题，以及若推翻上游 clarify.md 结论需说明以哪版为准。写完扫中文乱码：grep -rnI $'\xef\xbf\xbd' docs/prd/<feature-name>/