用途：把一条功能想法转化为 PRD。PRD 的核心是一行问题、用户旅程（每条旅程以可观察状态结尾）和交付切片；小改动只保留核心即可。旅程与切片的格式定义在 references/project-doc.md，编写前需先阅读。构建顺序、模块边界、逐文件设计不在此技能范围，属于 to-scaffold 与 to-tickets 的工作。
定位：它处于功能阶段，流程为 to-prd → to-scaffold → to-tickets → ticket-tracker；非代码工作可直接 to-prd → to-tickets。作品集到功能是多对多关系，一张路线图卡片对应一个功能，六个卡片应是六份 PRD，不能一份 PRD 覆盖整个路线图或方案文档。如果上游产物缺失，不应停下，也不要让用户回退。
先验信息：对话内容、./docs/approach.md 和 ./ideas/reports/*-ideate.md 可作为先验，可用 artifact-scan 定位（未安装则用 ls）。已有答案的问题可跳过，只需确认差异。没有先验也能运行完整访谈；先验属于作品集层级，若其包含多个功能且目标不明，需询问本次 PRD 针对哪一个。
流程：1) 让用户用自己的话详细描述问题与可能的解决思路；2) 探索仓库，验证其说法并了解现状，注意已有部分实现，使旅程建立在现有基础上；3) 围绕范围与行为进行追问，聚焦谁做什么、看到什么，而非构建顺序；4) 按参考格式为每种用户获得价值的方式撰写旅程，并与用户确认是否覆盖问题、每条旅程是否结束于可指认的状态，必要时可用 prototype 技能做原型；5) 切分交付切片，先问能交付核心结果的最小发布，再问后续，按用户价值排序而非技术依赖；6) 对较大功能，可选提供 why、goal、concepts、out of scope、open questions 层，小改动可跳过，且该层格式由用户决定，需询问用散文、表格、列表还是其他形式；7) 若 docs/prds/ 不存在则创建，将 PRD 写入 docs/prds/<feature>.md（kebab-case 命名），展示并确认，打印文件路径。
限制与说明：提交 GitHub issue 需用户主动要求，且基于文件以免副本漂移，命令为 gh issue create --title "[PRD] <Feature Name>" --body-file docs/prds/<feature>.md。完成后交接：代码工作用 /to-scaffold，非代码工作直接从 PRD 用 /to-tickets。结束时询问是否记录反馈，若否则调用 skill-feedback-collector 并传入技能名称与路径。