用途：为 Warp 中的重要功能编写 PRODUCT.md 产品规格，目标是把期望行为描述得足够明确，使智能体能够正确实现并避免回归。规格完全从消费者（用户）视角出发：描述用户看到什么、做什么、经历什么，以及必须始终坚持的不变量，不写实现细节（内部类型、状态布局、模块边界、数据流、算法）。“用户”不限于 Warp 终端用户，也指该表面（surface）的消费方：UI/UX 功能为使用 Warp 的人，数据模型为读写该模型的代码，API/协议/库为其调用方，CLI 或开发者工具为调用它的开发者。
用法：将规格写到 specs/<id>/PRODUCT.md，<id> 可为 Linear 工单号、带 gh- 前缀的 GitHub issue id，或简短 kebab-case 功能名；specs/ 下只允许以 id 命名的直接子目录。工单/issue 引用可选，仅当用户明确要求时才新建。写前先用 ask_user_question 收集缺失上下文：目录 id、功能概要、目标用户、关键行为、边界情况与验证方式，不要猜测。若功能含 UI 或交互设计，在起草行为部分前询问是否存在 Figma 稿并在规格中收录链接，无稿则显式写 Figma: none provided；纯后端功能跳过该问题。
结构：必写 Summary（1–3 句）与 Behavior（核心，编号、可测试的英文不变量）；可选 Problem、Goals/Non-goals、Figma、Open questions，仅在增加信息时保留，不写占位。不包含 Validation、Success criteria 或 Testing 章节，这些属于配套 TECH.md，由 write-tech-spec 技能产出。Behavior 应从用户视角穷尽默认流程、所有可见状态与转换、输入与响应、空/错误/加载/取消状态、易被忽略的边界（权限拒绝、离线、超时、竞态、并发实例、数据陈旧或缺失、焦点丢失、相邻功能交互）、键盘与无障碍与焦点预期，以及必须始终成立的不变量。
限制与维护：长度随功能复杂度而定，框架部分保持精简，长内容应集中在 Behavior。已批准的规格可随实现同一 PR 提交；当用户可见行为或 UX 细节变化时，应同步更新 PRODUCT.md，使签入规格描述实际发布的功能。大型功能可选维护 DECISIONS.md。相关技能包括 implement-specs、write-tech-spec、spec-driven-implementation。