用途：帮助撰写工程师真正会读的 PRD。核心观点是 PRD 是思考工具，篇幅应控制在 800 到 1200 词以内，最长不超过 1200 词，越短越可能被阅读、遵循并按时交付。
结构：除标注可选的章节外，每节均为必填。一是问题，以客户证据开篇，如引语、数据、工单、观察到的行为；若无证据须明确说明，并标注为观点驱动。二是目标，写可衡量结果并带数字，例如把某项流失从 60% 降到 30% 以下，而非“改善体验”。三是目标用户，要窄，例如“首个 PM 入职前的 A 轮创业公司创始人”。四是需求，用 P0/P1/P2：P0 缺了就不能发布；P1 缺了仍可发布但明显降级；P2 为加分项。每条需求一句话，过长即需拆分。五是成功指标，必须带数字，且每个指标配一个反向指标以防作弊，例如激活率升至 70% 的同时 30 日留存不低于 45%。六是范围之外，明确不做什么及原因。七是开放问题（可选），每个问题须写明由谁在何时回答。
准则：永远从带证据的问题出发，不从方案出发；不写实现细节，如架构、API、数据库模式；始终包含范围之外；需求必须可追溯到客户证据；禁止模糊指标，如“提升性能”“增强体验”，要么给数字要么删除；P0 需求应为 3 到 5 条，超过 5 条说明未做优先级排序。
示例：坏 P0“系统应以安全且用户友好的方式处理认证，支持多提供商与边缘情况”；好 P0“用户可用邮箱加密码注册登录。Google OAuth 为 P1”。
限制：本资料未提供具体收费、价格、平台或更多安装与使用步骤信息；该技能基于 Linear 的“短规格优于详尽文档”理念，来自 productskills。