product-planning：立「每份产出文档开头必须有图」（用户 2026-10-15 令）

- 主 skill 新增一节 `## 产出文档开头必须有图（单一真源）`，写明：图放标题之后、正文之前；
  按段定画什么（①段画对象与流向／②段画页面骨架／③段画页面结构与操作动线／④段画用户路径与四块怎么串）；
  画图用 `diagram-design`，⛔ 不手写 Mermaid；图与正文必须对得上。
- 四个 stage 的「硬约束」各加一条引用，指向该节 —— ⛔ 各段不复述口径（单一可信源）。
- 主 skill「反面清单」加一条：落盘文档开头不给图、或图与正文各说各的。
- 验收：check_naming.py --ws E:/ProgramData/AIProject/contentm_agent ＝ 通过 2063 / 失败 0 / 提示 27；
  工作区 CRLF 文件数 0。

product-planning/SKILL.md

@@ -221,6 +221,19 @@ DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec
 - **为什么**（避坑依据 · 2026-10-14 实测）：为问「原型说明文档该怎么写」，先铺了 1 500 余字的背景（含已废弃做法的 5 个设计点、4 条硬约束、7 个问题）⇒ 细节量压过问题本身。
 - **留痕**：提问原文与回答原文都要落盘；提问按本节写，⛔ 不把本机路径当内容（外部模型看不到本机路径，要么逐字内联、要么上传文件）。
 
+## 产出文档开头必须有图（单一真源）
+
+> 2026-10-15 用户令，逐字：「产品规划页面 所有文档前面都要画图」。各段一律引用本节，⛔ 不在段内另写一套口径。
+
+- 每份落盘文档**第一屏就给一张图**：图放在标题之后、正文之前 —— 不读正文也能先拿到全貌。
+- 图表达这份文档**覆盖的东西之间的关系**，按段定画什么：
+  · ①段（`research/` 五份）—— 画对象与流向：为谁解决什么、信息从哪来到哪去。
+  · ②段（`prd/` 两份）—— 画页面骨架：有哪几页、每页几个板块、跨页关系怎么走。
+  · ③段（`ui/` 下的产物与 `DESIGN.md`）—— 画页面结构与操作动线：用户办成一件事实际经过哪几页、每页做什么、哪里要来回跳。
+  · ④段（产品文档）—— 画用户路径：第一层轴那几段，以及每段四块（需求列表 → 用户场景 → 操作流程 → 功能）怎么串起来。
+- 画图用 `diagram-design`，⛔ 不手写 Mermaid（判据见「工具选择规则」那张表）。
+- 图里每格写清名字、线标方向；图与正文互相对得上 —— 正文新增或改了结构，图要跟着改，两处不许各说各的。
+
 ## 每段的标准收尾格式
 
 ```
@@ -261,6 +274,7 @@ DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec
 - 让③段顺手把说明区或产品文档写了（那是第④段 `stage-proto-doc` 的活）
 - ④段里重新规划产品、重新设计界面，或写原型上没有的页面 / 功能 / 业务规则（④段只解释与记录**现有**原型）
 - 问外部模型时堆砌背景：把过程留痕、废弃做法、内部约束清单整段贴进去（应按「征询外部模型（GPT）的提问口径」只给关键背景 ＋ 明确问题）
+- 落盘文档开头不给图，或图与正文各说各的（应按「产出文档开头必须有图」先上图、再写正文，两处对得上）
 - 过「说人话」时把「注入个性」那半也照做：加观点、加第一人称、写感官细节与比喻、允许跑题（应按内容准则只取「去 AI 味」那半，产出仍是客观书面说明文）
 
 ## 改名 / 改供给后的自检

product-planning/references/stage-delivery/SKILL.md

@@ -305,6 +305,7 @@ Gate-1 方向门（硬闸，不可跳）——按本表逐项自检（字段定
 `docs/pm/<项目>/ui/3d-审查报告.md`，固定七节：范围 + 挡位 + 阻断项表 + 建议项表 + 状态覆盖核对表 + 结构核对表 + Gate 结论（含「本轮是否跑了脚本」一句）。
 
 ## 硬约束
+- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。
 
 - ⭐⭐ 骨架冻结，不许动板块（2026-10-06 用户定案）：页面清单、每页板块、板块排列、跨页关系由②段《界面布局》定死。
   ⛔ 本段不许新增 / 移动 / 删除 / 合并板块。做不下来 / 觉得缺板块 ⇒ 回②段改《界面布局》，⛔ 不许就地加一块，就地加会让②段与原型不一致，下一个读原型的人拿到的是错的骨架。

product-planning/references/stage-discovery/SKILL.md

@@ -179,6 +179,7 @@ description: 产品规划第①段，产品需求。五个子步依次产出五
 > 修订后分工与用户原话：只在②段 `references/stage-requirements/SKILL.md` 的 §②—③ 交接口 定义一次，本段不复述。
 
 ## 硬约束
+- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。
 
 - 需求文档必做：`1a-需求文档.md` 存在（含"做什么 / 为谁 / 不做什么"＋决策表），且待复核清单已被用户过一遍。没有它不许开 1b——否则取证答的不是用户的问题。
 - ⭐⭐ 产出白名单（2026-10-06 用户定案）：本段产出仅五份（见开头「产出白名单」）。不许新增第 6 份，除非用户明确要求。

product-planning/references/stage-proto-doc/SKILL.md

@@ -115,6 +115,7 @@ description: 产品规划第④段，原型说明文档。在③段已跑通的
 - 缺失信息明确标记，不用推测性描述填空白。规则文件本身也用这套语体写。
 
 ## 硬约束
+- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。
 
 - 只用原型上真实存在的事实；每条说明都能在原型上指到对应元素。
 - 不擅自新增页面、功能、需求、业务规则或交互。

product-planning/references/stage-requirements/SKILL.md

@@ -111,6 +111,7 @@ description: 产品规划第②段，产品功能。只做一件事：把①段
 > ⚠️ 旧 `ux/diagrams/system-architecture.html` 画的是系统组件之间的关系，属实现视角，已改名。本段要的是页面与板块，属产品视角，⛔ 不许再叫「系统架构」。
 
 ## 硬约束
+- 每份产出文档**开头都要有一张图**（2026-10-15 用户令）：图放在标题之后、正文之前；画什么、用什么画，一律见 `product-planning` 的「产出文档开头必须有图」一节 —— ⛔ 本段不复述。
 
 - ⭐ 本段不是压测入口（2026-10-06）：`grill-me` 全场只有①段一份，火力点已扩到覆盖「做成什么样、状态怎么流转」。⛔ 本段不许再开一轮反问 —— ①段 `1a-需求文档.md` 的决策表就是本段的压测输入。用户始终不回应时①段怎么处理，本段照旧继承，但不再自己去问。
 - ⭐ 假设照旧继承，但账在①段：`1a-需求文档.md` 带进来的每条 `【假设】`，在②段落盘时逐条给结论，只允许三种归宿 —— 已确认（写明确认人与时间）｜待实现且已排定确认时机（写明「在第几步落地前必须问」）｜`【已按假设落地】`（写清影响面 + 回退口径）。⛔ 第四种（既未确认、已进实现、又无落地说明）不许带进本段。