用途：为 Hubble 的重要用户可见功能撰写 PRODUCT.md 规格。产品规格用于敲定产品决策并说明用户流程，是决策记录而非文档，写的是选择本身，而非推导理由；维护者应能在一分钟内读完并同意，或指出具体不同意的条目。用户指该界面的使用者：使用 Hubble 桌面或 Web 的人，或在 CLI 界面调用 hubble 的开发者。
主要能力与结构：规格包含 Summary（1-2 句说明功能与结果）、Flows（核心，逐步说明每个用户流程：起点、操作、每步所见，并把影响该流程的决策以短条目列在下方）、Out of scope（本切片刻意不做的内容）。仅在必要时可加 Problem（一段动机）与 Open questions。不包含实现、模块划分、工程验证或成功标准；端到端测试计划放在 TECH.md，并应直接源自本文 Flows。
用法：写入 specs/<id>/PRODUCT.md，其中 <id> 为带 gh- 前缀的 GitHub issue id（如 specs/gh-456/PRODUCT.md）或简短 kebab-case 功能名；specs/ 只应包含以 id 命名的目录作为直接子项。同一 id 的 TECH.md 使用同级路径。仅在用户明确要求时才创建 GitHub issue。写作前需收集：现有与期望的用户旅程、可复用的 Hubble 界面与设计系统原语（不要发明新视觉系统）、CONTEXT.md 中的项目词汇（Workspace、Workspace Folder、Plain Folder、Loose File、Cloud Sync、Markdown File、Asset、Embed、Embed Bundle、Workspace Snapshot）。
限制：不得涉及实现、内部类型、状态布局、数据流、模块架构或文件路径，这些属于 write-tech-spec 的 TECH.md。每条条目须是可测试、可观察的行为；先完整覆盖正常路径，再补答案不明显的边界情况（错误、空、离线、冲突、取消）。命名用户可感知的现有原语（dialog、toast、popover、menu item），而非从头描述新 UI。仅在行为确有差异时注明 Workspace 状态差异。总长度目标 20-60 行。行为变更时应在同一 PR 中更新 PRODUCT.md。相关技能：write-tech-spec、to-issues、grill-with-docs。