用途：将当前对话上下文和代码库理解综合成产品需求文档（PRD），并发布到项目 issue tracker。触发场景是用户希望基于当前上下文创建 PRD。
主要能力与流程：技能不采访用户，只综合已有信息。若尚未完成，先探索仓库以了解代码库现状；使用项目领域词汇表中的术语，并遵守相关领域的 ADR。随后勾勒实现所需构建或修改的主要模块，主动寻找可抽取为深模块（用简单、可测试、少变化的接口封装大量功能）的机会。接着与用户确认这些模块是否符合预期，并确认希望为哪些模块编写测试。之后按给定模板撰写 PRD 并发布到 issue tracker，打上 needs-triage 标签，使其进入常规分诊流程。
PRD 模板包含：问题陈述（从用户视角描述用户面临的问题）、解决方案（从用户视角描述）、用户故事（很长的编号列表，格式为 As an …, I want a …, so that …，需覆盖功能所有方面）、实现决策（要构建或修改的模块、模块接口、开发者的技术澄清、架构决策、schema 变更、API 契约、具体交互；不包含具体文件路径或代码片段）、测试决策（好测试的定义，即只测外部行为而非实现细节；将测试哪些模块；测试的先前实例，即代码库中类似测试）、范围之外（描述超出本 PRD 范围的内容）、进一步说明。
必要用法：issue tracker 需能通过 gh 访问；如需要标签词汇，查看项目的 AGENTS.md 或 issue 模板。
限制：不采访用户；实现决策中不写具体文件路径或代码片段，以免很快过时。其余收费、平台、价格等信息资料未提供。