用途：当需要编写 PRD、功能规格或需求文档时使用该技能，把模糊想法转成结构化需求，作为“要做什么、为什么做”的依据。不适合把已有 PRD 拆成 issue、纯技术设计文档、缺陷报告或事后复盘，也无需用于小修复。
主要能力：先评估适用格式——新功能/多干系人用完整 PRD；范围清晰的小增强用轻量 PRD；AI/ML 行为难以用文字描述时用评估优先 PRD；问题已明确时用仅用户故事格式。流程分五阶段：发现、分析、起草、验证、定稿。发现阶段必须收集问题空间并探索代码库，识别架构、模式、模块、数据模型与测试惯例；若目标代码库不明确则标为 TBD。分析阶段进行代码库感知的边界情况分析，必要时给出 2-3 个架构选项的优劣与成本，不替用户决定架构。起草阶段按模板写 PRD，完整 PRD 含问题陈述、为何现在、成功指标、用户画像、用户故事与验收标准、方案概述、技术约束与非功能需求、测试策略、范围外与非目标、风险依赖与开放问题。验证阶段检查要求是否可度量、验收标准是否原子且二元、成功指标是否有基线与目标、非功能需求是否有数值阈值等。定稿可写入 GitHub Issue（gh issue create）或 docs/prd/{feature-name}.md，也可两者兼做。
限制：未完成发现不要写 PRD；至少先提 3 个澄清问题，否则记录至少 3 个明确开放问题并标 TBD。PRD 中不要放文件路径或代码片段，使用模块/组件名。不要使用“快”“易用”等无阈值表述。不要编造约束，缺失信息应询问或标 TBD。单一 PRD 离散需求不应超过 200 条。GitHub issue 正文超过 60000 字符需拆分，可参考 issue-size-management。输出物是 PRD 而非实现计划，实现方式应在批准后使用 plan-work 或 plan-issue-tree。