用途：帮助撰写或审查产品需求文档（PRD），传达意图、范围与约束，而非过度规定实现方式。调用方式为 /prd-writing 将 PRD 约束应用到当前对话，或 /prd-writing <feature> 为指定功能起草或评审 PRD。
主要能力与结构：必须以问题开头而非解决方案，问题陈述需让新成员在 60 秒内理解，并包含用户证据（数据、引述、支持工单）而非仅凭直觉。小型功能用一页式：问题、建议方案、成功指标、范围边界、待决问题；大型项目用完整 PRD：背景、含证据的问题、目标、用户故事、需求、范围内/外、设计考量、发布计划、风险。每节需通过“那又怎样”测试，除真正必要外不超过 3 页。
范围纪律：必须包含明确“不在范围内”一节；对每条需求回答“v1 是否必需”；需求超出原问题时应标记范围蔓延，扩大范围须重新评估时间与资源。
成功指标：须定义 1-3 个具体可衡量结果，每个说明测什么、如何测、目标与评估时间线，例如将任务完成时间减少 20%，不写“改善用户体验”。
工程同理心：定义“做什么”而非“怎么做”，不规定实现细节，尊重读者时间，呈现边界情况、失败状态与异常输入，并随范围变化持续更新。
反模式：无人读完的冗长文档、方案先行、规定 API 等实现方式、写完不再更新的静态产物、无法失败的空泛指标。
限制：资料未提供该技能的收费、平台支持范围、具体安装命令及实际效果验证信息。