用途：把已经聊透的需求上下文直接成文为 PRD，不做采访。适用前提是问题、用户、范围、边界都已有结论，只差落到文档；需求仍停留在口头、边界未问清时，应改用 requirement-clarify；需要复用产品体验基线或做增量 PRD 时用 prd-write；评审已成文 PRD 用 grill-with-prd。
主要能力与流程：其一，梳理上下文中已定内容，包括问题、目标角色、范围、明确不做、已知约束与验收口径，未定项写入第 9 节「待决问题」并标明归属人，不替用户拍板。其二，探索代码库，使用项目领域词汇，遵守相关 ADR。其三，梳理需新建或修改的主要模块，寻找可独立测试的深度模块机会，与用户确认划分及测试范围，结论写入第 10 节「交接说明」，不写入第 7 节。其四，以 template.md 的 0–10 节为骨架成文，写入 docs/prd/<feature-name>/prd.md（目录不存在时自动创建），模式分 full 与 incremental；第 7 节按用户可验证行为组织，写清角色、触发条件、主流程、状态变化、权限、异常与验收结果；事实标来源，推断标 [INFERRED]，无法确认的进第 9 节，不为填满模板编内容。
使用方式：先确定功能名（小写短横线，如 user-auth、payment-flow），目标为 docs/prd/<feature-name>/prd.md；已有同名 PRD 时先问用户是更新、另建目录还是保留原文，不得静默覆盖；查 docs/product/<project-name>/，有基线就读入写入第 2 节，没有写「无基线」。交付前检查结构是否与 template.md 的 0–10 节一致、已有 prd.md 是否被误覆盖、未定项是否都在第 9 节、第 7 节是否为用户可验证行为，并可用 grep -rnI $'\xef\xbf\xbd' docs/prd/<feature-name>/ 扫乱码。
限制：不采访用户；不替用户决定未讨论过的业务决策，只摆清选项与后果；不写代码、不写文件路径；不因模板留空而编造内容；与 prd-write 产出同一 prd.md，不要连着跑。其余如收费、价格、平台等信息资料未提供。