用途：当用户想要撰写 PRD 时可调用该技能。它支持两种模式：用户仍在构思阶段时采用访谈驱动；若当前对话已有具体问题、方案、原型、缺陷报告或既往代码库分析，则切换为上下文优先模式，先综合已知信息并对照仓库核验，只追问阻塞性问题。
主要能力：向用户获取问题的详细描述与潜在解决思路；探索仓库以核验用户说法并理解代码库现状，沿用项目领域词汇并尊重相关 ADR 或架构文档；围绕方案各分支持续访谈直至达成共识；勾勒需要构建或修改的主要模块，寻找可在简单、可测试接口中封装大量功能、且接口很少变化的深层模块，并与用户确认模块是否符合预期及需要为哪些模块编写测试。
使用方式：完整理解问题与方案后，按模板撰写 PRD，保存到项目根目录的 docs/prds/<slug>.md（目录不存在则创建），文件名使用描述性的 kebab-case slug，例如 docs/prds/user-authentication.md，并告知用户创建路径。PRD 需面向初级开发者：逐步说明实现路径、解释陌生术语、明确依赖，避免假设实现者了解对话中的隐藏上下文。
文档结构：问题陈述、解决方案、用户故事（冗长编号列表，格式为 As an ... I want a ... so that ...）、实现决策（模块、接口、技术澄清、架构决策、模式变更、API 契约、具体交互；不写具体文件路径或代码片段，除非原型、状态机、reducer、模式、类型形状或 API 契约能比文字更精确地表达决策，此时只内联富含决策的部分并说明原因）、面向初级开发者的逐步实现计划（说明改什么、为何在此顺序、影响哪个模块/接口/契约/模式/流程、下一步前需验证什么、常见陷阱或需避免的假设，足够具体但不依赖脆弱行号或代码片段）、测试决策（好测试的定义、测试模块、代码库中同类测试先例）、范围外内容、进一步说明。
限制：资料未提供收费、价格、平台或集成方式等信息。该技能依赖用户访谈与代码库访问；若上下文不足需先提问，无法核验仓库时相关结论可能不准确。