product-blueprint

name	product-blueprint
description	生成或更新产品蓝图与场景说明。聚焦产品定位、市场洞察、用户场景与边界决策，为 Feature List、Spec、PRD 与原型提供上游输入；兼容 0-1 新产品与 1-n 版本迭代。

产品蓝图与场景说明（Product Blueprint）

用于在产品设计早期或版本规划时，输出一份结构化的「产品蓝图与场景说明」文档。该文档是 Feature List、Spec、PRD 与原型的上游信息源，统一描述产品定位、市场洞察、目标用户、关键场景与边界决策，兼容从 0-1 与 1-n 两种场景。

---

何时使用

• 从 0-1 设计一个新产品/子系统时，希望先理清「是谁、在什么场景下、要解决什么问题」。
• 在 1-n 迭代 时，希望在改动 Feature List/PRD 之前，先明确本次版本的业务目标、范围与受影响场景。
• 希望让后续的 Feature List、Spec、PRD 与原型都有统一的「场景 ID / 能力 ID」来源，便于追溯与自动生成。

补充说明：

• 当用户仅需“基于截图/想法快速产出单篇 PRD”时，可先跳过本 skill；
• 进入多需求协作或原型体系化阶段时，建议回补蓝图以统一场景与能力来源。

---

方法论导向（原则）

本 skill 采用“方法约束，不固定问卷”策略。可参考但不限于以下方法：

• Double Diamond：先发散再收敛，避免一开始就锁死方案。
• JTBD：先明确“要完成的任务”，再讨论功能形态。
• OST（Opportunity Solution Tree）：把目标、机会与方案连接起来，避免功能堆砌。

执行上不要求机械套模板，重点是：

• 先问能改变方向的问题；
• 持续下钻关键分支直到可决策；
• 每轮输出“已确认/待确认/冲突点”并收敛。

---

访谈执行规则（强制）

1. 目标导向提问
   • 先问会改变方案方向的问题，不问装饰性问题。
2. 设计树下钻
   • 沿关键分支持续追问，直到该分支可决策。
3. 依赖消解
   • 将互相依赖的决策拆开，按顺序确认，避免并行拍脑袋。
4. 收敛检查点
   • 每轮只输出：已确认、待确认、冲突点。
   • 未收敛不进入下一产出阶段。
5. 粒度匹配
   • Blueprint 只做全局层决策，不进入 PRD 细节。
6. 可跳步但需解释
   • 可跳过非关键步骤，但必须说明为什么可跳。

---

竞品扫描（默认必做）

• 在蓝图阶段默认执行竞品/替代方案扫描（建议 3-5 个），除非用户明确要求跳过。
• 来源需可追溯（官网、帮助中心、定价页、发布说明、公开评测）；禁止仅凭记忆下结论。
• 输出至少包含：
  • 竞品名称
  • 目标用户与核心场景
  • 相关能力与差异点
  • 对我方定位的启示
• 证据不足的判断必须标注「待验证」。

---

文档结构（建议模板）

具体章节命名与顺序以项目内标准参考文档为准，若项目未约定，可采用以下模板生成 ${DOC_ROOT}/01_blueprint.md（默认文档根为 docs/）：

1. 版本信息与范围
   • 本次蓝图适用的产品/子系统名称、版本范围（如 V1.0 全量、V2.1 告警优化）。
   • 可选：本轮先做项（目标项ID（feature_id 或 module_id） 或模块名），用于下游直接进入单项闭环。
2. 产品定位与价值主张
   • 目标市场、替代方案、差异化主张。
3. 目标用户与核心场景
   • 主角色、关键任务、触发频次/痛点强度。
4. 市场洞察与机会判断
   • 竞品格局、机会窗口、进入理由（含证据来源）。
5. 商业目标与成功指标
   • 北极星与阶段性目标（可量化或可验证）。
6. 关键场景列表
   • 为每个关键场景分配唯一 ID（如 SCN-01-设备告警处理），并描述：
     • 场景名称
     • 触发条件
     • 主流程概览
     • 成功结果/完成判据
7. 能力地图草图（领域-模块-能力）
   • 按「〇级领域 → 一级模块 → 二级能力」的层级列出能力树，为每个节点分配可选 ID（如 DM-设备管理、ALR-告警管理 等）。
   • 能力地图将直接为后续 Feature List 的 〇级～二级提供骨架。
8. 产品边界（本次做/不做）
   • 明确本次蓝图/版本不解决的需求或场景，避免 scope 扩散。
9. 关键约束
   • 合规、资源、组织、交付周期、技术前提等上位约束。
10. 核心风险与验证假设

• 最高风险假设、验证路径与判定标准。

11. 阶段策略（MVP 与里程碑）

• MVP 定义、阶段切分、Go/No-Go 条件。

12. 冻结边界（进入原型前）

• 明确本轮冻结项：业务目标、关键流程、关键约束。
• 冻结项在原型阶段不可擅自改动，变更需走回写流程。

13. 待确认项

• 未确认的信息必须集中登记（按优先级与责任人标注）。
• 下游 Spec/PRD/原型不得将待确认项当成已确认事实。

---

0-1 与 1-n 场景的写作方式

• 0-1 场景（新产品/新子系统）：
  • 输入通常只有一句话项目描述、行业/目标人群、少量参考产品链接。
  • 本 skill 应：
    • 先根据输入起草「需求背景与业务目标」；
    • 推导出主要用户角色与 3～7 个关键场景；
    • 给出初版能力地图草图（领域/模块/能力），并为场景/能力分配 ID；
    • 将以上内容写入或新建蓝图文档。
• 1-n 场景（版本迭代/模块增强）：
  • 输入通常包含版本号、本次想改善的问题或模块、现有文档链接等。
  • 本 skill 应：
    • 读取已有蓝图、Feature List 与 PRD，概括当前能力与场景覆盖情况；
    • 在蓝图中新增一节或一小段，专门描述「本次版本的目标与范围」；
    • 标出哪些场景/能力是新增、优化或下线，为后续 Feature List 与 PRD 更新提供依据。
    • 若用户指定先做项，应在蓝图中显式标注该项，供下游优先执行。

---

本地环境下的默认落盘行为（Cursor / Codex）

• 在本地可写文件的环境中，使用本 skill 时应遵循以下默认行为：
  1. 优先读取项目标准文档：查找并读取项目中的标准参考文档，以获取文档根（如 docs/）与蓝图文件路径约定。优先级建议为：
     • 项目文档根或 docs/ 等目录下的 product-doc-standard/README.md；
     • 其他等价命名的标准文档：docs/PRODUCT_DOC_STRUCTURE.md、docs/产品文档结构规范.md、文档根下 PRODUCT_DOC_STRUCTURE.md。
  2. 若无标准文档则创建最小模板：当项目中未发现任何标准文档时，应在仓库根创建 product-doc-standard/README.md，约定：
     • 文档根目录：默认为 docs/；
     • 蓝图默认路径：默认为 docs/01_blueprint.md；
     • 后续可由项目成员按需扩展与修改。
  3. 保证蓝图文件存在：根据标准文档中的约定路径（或默认路径）创建或更新蓝图文件；若文件不存在则新建，并填充完整结构。
  4. 显式反馈文件变更：在对话中简要列出本次新建或更新的蓝图文件路径，便于用户在编辑器中打开查看。

---

与其它 Skill 的配合

• product-featurelist：应将蓝图中的领域/模块/能力与场景 ID 作为 〇级～二级的输入骨架，使 Feature List 中的编号可以回溯到具体场景/能力。
• product-spec：Spec 应承接蓝图中的场景 ID、能力 ID、页面范围建议与非范围约束，作为 PRD 与原型的中间事实层。
• product-prd：PRD Header 中的「对应 FeatureList 编号」「对应场景 ID」应能够反查到本蓝图文档中的对应条目。
• product-design-flow（若存在）：可在 0-1 与 1-n 模式下先调用本 skill 生成/更新蓝图，再自动调用 Feature List、Spec、PRD 相关技能。

本 skill 只负责「蓝图与场景」层，不直接定义具体字段规格或页面交互，这些由 Feature List 与 PRD 等下游文档承接。