workbuddy_skills/product-planning/SKILL.md

name, description

name	description
product-planning	产品规划总入口（唯一入口），四段式调度：① 产品需求 ② 产品功能 ③ 界面交互 ④ 原型说明文档。四段以 references/stage-* 承载，本文件是总调度与约束。可整段跑也可只调一段。当用户要做产品规划、从零做新产品、只做某一阶段、或不知道从哪开始时调用。

产品规划总入口

本 skill 由模型按需自动加载，没有斜杠命令。对话里还没定出对象时，先按「项目与路径约定」定出 <项目>；定不出来就停下问用户，不要自行假设。

用途

用户丢来一句模糊想法（例如「我要做一个 AI 短剧分镜画布」）时，本 skill 判断该走哪一段，只做那一段的最小必要工作，产出可交付物，再推进到下一段。

本文件管调度与约束。各段怎么做，写在 references/stage-* 各自的文件里。

四段结构（可整段跑，也可只调一段）

段	回答的问题	子步	调用	产出物
① 产品需求	要做的东西凭什么成立：什么问题、为谁、为什么值得做	1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景	stage-discovery	docs/pm/<项目>/research/*。其中 1b 交两种体例：research/1b-竞品分析.md（汇总对比）＋ research/1b-独立分析/<竞品名>.md（独立分析）
② 产品功能	要做哪些功能、什么不做、长成什么骨架	2a 产品功能 / 2b 界面布局	stage-requirements	docs/pm/<项目>/prd/2a-产品功能.md 与 prd/2b-界面布局.md（两份）
③ 界面交互	长什么样、怎么操作	3a 视觉规范 / 3b 原型 / 3c GPT参考版 / 3d 审查打磨	stage-delivery	docs/pm/<项目>/DESIGN.md、docs/pm/<项目>/ui/*.html、docs/pm/<项目>/ui/3c-GPT参考版.md
④ 原型说明文档	现有原型怎么用、每条需求落到哪、坏了怎样、怎么核对（按用户路径分段，每段四块：需求列表 → 用户场景 → 操作流程 → 功能）	4a 场景盘点 / 4b 说明区 / 4c 演示引导（可选）	stage-proto-doc	原型内嵌说明区 ＋ 独立产品文档 docs/pm/<项目>/ui/产品文档.html（两份共用同一套 R/S/F 编号）

四段只通过落盘文件耦合。段间交接口如下，这是唯一的契约，越界即失效：

交接	由谁给	给什么	给到哪为止
① → ②	①	问题定义、需求澄清决策表（含 grill 压测的 B 节：做成什么样 / 哪些情况不成立 / 状态怎么流转）、取证结论（1b 汇总对比体 ＋ 1b 独立分析体、1c 用户画像）、产品定位、《使用场景》＝用户故事（②段功能的直接推导依据）	功能清单归②段产出，1a 写到需求与形态为止
② → ③	②	功能清单（每条带优先级 ＋ 状态流转）、界面布局（有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系）、每页主操作、信息承载分档（主屏常驻 / 可点入）	视觉归③段。骨架必须给全，骨架不给全，③段就一版一个样
③ → ④	③	已跑通的单文件原型 HTML（页面、模块、控件、状态、交互、跳转、反馈＝界面事实的唯一依据）	说明区与独立产品文档归④段；⛔ ④段不重新规划产品、不重新设计界面

口径：②段钉骨架，③段做皮肉。两侧逐行对照与用户原话只在②段 references/stage-requirements/SKILL.md 的 §②—③ 交接口 定义一次 —— 本入口不复述。要点两条：②段要给全「归②段」列；③段不许增删移动板块，缺板块回②段改。

②→③ 最容易搞坏。旧病灶：②段说「必须能读到」，③段读成「必须常驻主屏」，五类信息就全铺一屏成了信息墙。分档表把「读到」明确成「一次点击内可达」，防的就是这句歧义。骨架是灰块（有哪些块、什么顺序），③段给的是视觉与交互实现（排版、点哪有什么反馈、空态、响应式）。两件事各管一维，③段不会退化成照抄。

四段各占一个词，互不共用（2026-10-02 定）：产品 / 功能 / 界面 / 说明。改段名前先对照这张表；两个段名里出现同一个词，边界一定在漂。旧名「调研与方案 / 需求与结构」都含「需求」，③段旧名里的「交付」是三段共有的属性，都属名实不符，已改。 🔴 ④段的沿革（2026-10-14 → 10-15）：10-14 按用户令删掉旧版④段 —— 旧做法是往原型 HTML 注入说明区注解层（状态 → 场景 → 从左到右流程图 → 功能作用/输入边界/异常情况 三段 → 逐步骤演示引导），实测没法用，整段连方法论一并撤掉。10-15 用备份里的新版④段装上：改成「解释与记录现有原型」，交两份产物（原型内嵌说明区 ＋ 独立产品文档 docs/pm/<项目>/ui/产品文档.html），内容按「需求列表 → 用户场景 → 操作流程 → 功能」四块 ＋ 附录铺，配 R/S/F 编号体系与语体规范。判据正文在 references/stage-proto-doc/，⛔ 旧版那套（状态轴、三段必填、逐步骤演示）不再使用。 ①叫「产品需求」不叫「需求调研」：该段产出 research/1a-需求文档.md、1b-竞品分析.md、1c-用户画像.md，也产出 1d-产品策略.md、1e-使用场景.md，「调研」二字盖不住后半截。 ⭐ 1b 是①段唯一交两种体例的子步：独立分析体 research/1b-独立分析/<竞品名>.md（竞品池每一个一份），汇总对比体 research/1b-竞品分析.md（恒一份）。职责边界与定案原话见 references/stage-discovery/references/competitor-analysis.md §0.4。

⭐ grill-me 全场只有①段一份（2026-10-06 用户定案）：①段那份按 A / B 两节提问，火力点划分、节次归属与定案原话见 references/stage-discovery/references/grill-me.md —— ⛔ 本入口不复述。B 节结论落进 research/1a-需求文档.md。

⭐ ②段产出两份（2026-10-06 收窄，2026-10-07 定为两份）：prd/2a-产品功能.md（功能清单：做哪些 / 不做哪些 / 每条带优先级 ＋ 状态流转）与 prd/2b-界面布局.md（页面关系 ＋ 页面内板块布局）。定案原话与理由见 references/stage-requirements/SKILL.md 开头。

（交接口反转前的口径、②段收窄前的产出清单与去向 → references/_留痕/③段与总入口-旧口径.md）

⚠️ ①段功能按「使用场景」组织（一条场景可跨多个页面），不按页面组织。

段内的子步顺序、方法论文档、硬约束、完成标准，都在各段自己的 SKILL.md 与 references/ 里。

①段 1a 需求文档：全程最先做，且只做一次。用 grill-me 与用户互动，产出 docs/pm/<项目>/research/1a-需求文档.md（开头写清做什么 / 为谁 / 不做什么，往下是决策表）。

项目与路径约定（单一真源）

四段全部遵守本节。各段 SKILL.md 与 references/ 里出现 docs/pm/... 时，<项目> 一律指本节定义的 slug。

<项目> 是什么

项目 slug 用小写字母、数字、连字符（例 my-tool、video-canvas）。它就是 docs/pm/<项目>/ 这一层的目录名，一个字都不能差；各段产物都挂在它下面 —— ①段 research/、②段 prd/、③段与④段 ui/、跨段 专题/。

slug 怎么定（按序取第一个成立的）

序	条件	取值
1	用户在当前会话里明确说了项目名	该名字 slug 化
2	.registry/current-project 存在且非空	其内容
3	docs/pm/ 下恰有一个非 _ 开头的目录	该目录名
4	以上都不成立	停下问用户

写任何文件之前先核对：目标路径里的 <项目> 段与按上表得出的 slug 是否一致。不一致就停下说明，不要「先写了再说」——猜错会把产物写进别的项目，事后极难拆干净。

产物落哪

段	路径
① 产品需求	docs/pm/<项目>/research/
②	docs/pm/<项目>/prd/
③	docs/pm/<项目>/DESIGN.md、docs/pm/<项目>/ui/*.html、docs/pm/<项目>/ui/3c-GPT参考版.md
④	原型内嵌说明区（写进 docs/pm/<项目>/ui/*.html 自身）＋ 独立产品文档 docs/pm/<项目>/ui/产品文档.html

文档的两态：当前版与过期版

用户令（2026-10-11 逐字）：「应该有文件夹 专门归档过期文档， 当前文档 统一放在方案文件夹中」。

🔴 方案文件夹 ＝ docs/pm/<项目>/ 这一层 —— 它下面放的全是当前权威版：①段 research/、②段 prd/、③段 ui/、跨段 专题/，另加一份 索引-当前权威版.md 当入口。 🔴 归档文件夹 ＝ docs/pm/<项目>/归档-过期版/ —— 被顶替下来的旧版全放这里，命名 <原名>__<来源目标短哈希>.<扩展名>（例 2b-界面布局-新版__fc471a.md）。

每个目标收口时做四步： 1、本目标的权威文档覆盖方案文件夹里对应的那一份。 2、被顶替的旧版移进 归档-过期版/，按上面的命名补上来源短哈希。 3、更新 索引-当前权威版.md 里对应行的大小与日期。 4、执行区（执行会话/目标-*/ 这类过程目录）里的原件保留 —— 它既是过程留痕，也是台账 artifact 指向的地方，搬空会让回查断链。

为什么要有这条（避坑依据 · 2026-10-11 实测）：同一个 2a-产品功能 在 6 个目标目录里各有版本、2b 有 7 个，光看文件名与字节数分不出谁新；而 docs/pm/ 下早先那次归档又停在旧版（2b 只 52 256 B，最新已是 52 643 B）⇒ 用户问「很多新老方案都在文件夹中，后续根据方案细化产品界面，如何找得到对应的方案」。判断某份文档的当前版，只看方案文件夹；问「当时为什么这么定」才去归档文件夹翻。

DESIGN.md 为什么在项目目录、不在仓库根

DESIGN.md 是③段的绑定视觉规范，一个项目一份，③段按当前项目的 slug 去读它。仓库根只能放一份，多项目会互相覆盖，所以一律放 docs/pm/<项目>/DESIGN.md。

推论（硬规则）：读 DESIGN.md 时，路径必须由本节定义的 <项目> slug 拼出，不许用「当前工作目录碰巧有 DESIGN.md」这类推断。仓库根不放任何项目的 DESIGN.md。

工具选择规则（防止选错，最重要的一节）

下表是选型总则。这些工具都已封装在对应段内，本文件只负责让你不选错；具体调用路径见各段 SKILL.md。

要什么	用谁	别用
页面设计全链（规范 → 原型 → 审查）	③段 stage-delivery 自己的 D0→D5 流水线	另找风格库，或自己手搓一套 token 与门禁
评审用的可点原型 / 生产级前端页面	③段 3b（按 D2 构建，单文件 HTML 交付）。先判页型：营销页取③段 §供给·版式骨架 的可选档，工具型页面取其默认档	不判页型就套可选档种子——那是营销落地页骨架，会把后台做成营销页
设计规范文件	③段 3a 生成 DESIGN.md（令牌表取自③段选定套，见③段 §供给·定调与令牌；再加该项目②段的界面需求）	凭空编一套 token
架构图 / 流程图 / 时序图	diagram-design	手写 Mermaid
状态迁移的守卫、副作用、并发	state-machine	指望 diagram-design 覆盖这些
审美方向 / 风格定调	③段 §供给·定调与令牌 的默认档里选一套（可选档亦见该处），读候选套按页面类型挑。⛔ 每次只选一套	「米白＋衬线＋陶土色」这类默认审美，或凭感觉编
多方向比选 / 独立评审打分	③段 §供给·多方向比选 与 §供给·独立评审协议	拿它的评分循环替代本段 Gate-1/2/3

③段的页面设计供给 —— 默认主线、定调与令牌、版式骨架、工艺数值判据、独立评审协议、多方向比选，共六档；各档的默认来源 / 可选来源 / 路径只在③段 references/stage-delivery/SKILL.md 的 §供给 定义一次，本入口不复述，要改供给只改那一块（2026-10-08 起）。oil-ui-pro 是界面设计方法论：五步流程（探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付），加风格对比页与截图工具；它自带联网版本检查与自动更新，是用户明确要求全量搬入的例外项（既有纪律是「依赖外部服务一律不收」），已记录在案，不扩散。

默认走 oil-ui-pro 主线，不与可选档缝成一条流水线：可选档只在 §供给 里列，选了才作补强（多一路定调候选、多一套工艺数值判据），不选也不影响开工。

四样东西供给件里都没有对应，由 stage-delivery 自己扛：设计契约十二字段、结构骨架、交互清单、工具型版式库。

页型分流（2026-10-05 新增）：③段 §供给·版式骨架 的可选档是营销落地页向，工具型页面照它做会长出「标题上下各一行小字」的三段式（骨架名单与理由见③段 references/stage-delivery/references/layouts-tooling.md 开头）。本项目实测踩过这个坑，结构判据全绿也拦不住。所以③段 D0 必须先判页型，工具型页面版式一律走 §供给·版式骨架 的默认档。

只读一处来源：同一条判据若在默认档与可选档各有一份且口径不同，以本项目追加条为准 —— ⛔ 但追加条不得放宽基础层（oil-ui-pro 是基础层、其余是叠加层，分层规则见③段 §供给），并在 runbook §3.4 显式标注「本项目追加」。

DESIGN.md 说明：@google/design.md 提供 lint / diff / export / spec 四个子命令，目前是 alpha（v0.4.0）。非 TTY 的管道里可能不回显输出，需在真实终端里确认。本机实测该命令完全不可用，不要拿它当校验关卡；改由 D3 收口与 D5 终检按真实像素人工复测对比度（判据见③段 §供给·工艺数值判据 里配色那一份）。原两把门禁脚本（静态文案检查 / 渲染机检）已随旧主干从磁盘移除，当前没有机器复现，结论只能记「人工判定」，不得写成「脚本已通过」。

可调用工具（自然语言触发）

两个独立工具，按用户说法直接触发，产物落项目目录。design-capture 随③段携带（装在③段 references/stage-delivery/assets/ 下）；video-capture 2026-10-11 已独立成全局技能（装在技能根下的 video-capture/），跨段复用。两者都不单独成段。

用户说	触发工具	做什么	产物
「分析 XXX 视频」「把这个视频抽帧」「拆一下这条视频的画面」	全局技能 video-capture	取视频（本地文件 / 直链 URL / 平台页经浏览器下到本地）＋ 抽帧（双因素 ＋ 首尾 ＋ 补帧）	关键帧 c_<序号>_<真实秒数>s.jpg ＋ frame_times.json（供①竞品分析、③视觉参考）
「获取 XXX 网站的设计风格」「抓这个网站的风格/组件/配色」	stage-delivery/assets/design-capture/	抓网页设计系统（色彩 / 排版 / 组件），生成样式模板	一套 design-system-<名>/（与 design-system-tiaoyue 同构，可直接被③段 D1 选用）

两者都独立可单跑：video-capture 只依赖 ffmpeg（权威件＝全局技能 video-capture；原 stage-delivery/assets/video-capture/ 只留交接说明，脚本迁至 references/_留痕/video-capture-已独立-20261011/ 留档）；design-capture 只依赖本机 Chrome（CDP）＋ vendor/ 里搬运的抽取脚本，不需要任何外部服务在场。用法与边界见各自 SKILL.md，来源与署名见各自 ATTRIBUTION.md。

触发时机：①②段拆竞品视频用全局技能 video-capture；③段要新建样式或拆参考站用 design-capture。

两个工具都只做合规最小集：不抓平台页内视频，不调付费接口；抽取结果须先目视比对再采用。

进入方式

你说什么	模式	从哪开始
「规划 XX」「从零做 XX」	全流程（自动处理）	stage-discovery → stage-requirements → stage-delivery → stage-proto-doc，一路跑完，段间不停下来问（含①段末）
「先确认方案」「跑完方案停下等我」「规划 XX，先给方案」	方案确认	同一套四段，唯一差别是①段末停下等你确认方案，确认后才进②③④
「只做产品需求」「只做产品功能」「只做界面交互」「只做原型说明文档」	单段	只调对应那一个 stage skill，不展开其他段
已有②段，要出原型	单段	直接调 stage-delivery，从它的 3a 起
已有原型，要补说明	单段	直接调 stage-proto-doc，从它的 4a 起
只问某个单点	单段	不跑任何段，在对应 stage skill 内点名子步，或直接说要看哪份方法论

「只调一段」成立的原因：四段之间只通过落盘文件耦合，没有隐式状态。

• ②只读 docs/pm/<项目>/research/*；缺失时标注 【假设】继续，不催促回补①
• ③只读 docs/pm/<项目>/prd/*；缺失时同样标 【假设】继续
• ④只读 docs/pm/<项目>/ui/*.html（界面事实的唯一依据），另按需读 docs/pm/<项目>/prd/* 与 research/1a-需求文档.md 定业务意图；缺失时标 【假设】继续，并在段末偏离单里写明

执行规则

只有三种模式，没有第四种：

模式	段之间	段之内
全流程（自动处理）	一路跑完，段间不停下来问（含①段末）。每段结束按「标准收尾格式」输出一段报告，输出完即刻进下一段	子步之间不反问，做完直接进下一个子步
方案确认	与全流程完全相同，只有一处不同：①段末停下等你确认方案；确认后②③④一路跑完、段间不停	同上
单段	不涉及	不越界，不催促回补前段

这两条是全流程模式下的两个独立分支，不要混：全流程（自动处理）没有①段末的强制停；「停下等确认方案」只在「方案确认」模式下发生。二选一由用户定（界面里点【生成原型和文档】时选「自动处理」或「先确认方案」，或在会话里直接说明）；用户没明说时按自动处理走，不要在自动处理模式下自作主张停下来问。

「停下」指什么，不要读成「每一步都要反问用户」。只有这四种情况才停：

1. 信息不足且查不到，必须用户给（如「项目与路径约定」slug 第 4 条）——停下问
2. 破坏性 / 不可逆动作——二次确认
3. 用户显式要求某个子步做完停下
4. ①段末的方案确认（仅「方案确认」模式）——把方案摆给用户：做什么 / 不做什么 / MVP 边界 / 未复核的 【假设】，明说「等你确认方案，确认前不进②段」

段末报告：全流程（自动处理）模式下，所有段（含①）都只输出报告，不提问、不等回答；方案确认模式下①段是唯一例外，其余段同样只输出报告。

①段末的确认是回环，不是一次问答（仅「方案确认」模式）：用户看到方案后可以提问题要求改，可能多轮，每轮的「问题＋怎么改的」都要留痕、不得覆盖上一轮；改完由用户显式说「确认方案」才算过闸门。该模式下，没拿到用户确认的方案不得当成既定事实带进②段——这是实测踩过的坑：②段拿着未经确认的方案往下跑，把用户已拍板的需求裁掉了。

其余规则：

• 声明制（全段适用，不止③段）：开工前、每进一个子段或子步、每处偏离，都要声明三件事——当前在哪、依据哪个文件的哪一节、产出落哪；偏离当场写明原因与影响，段末附偏离单。不许静默偏离。实测踩过的坑：③段 3b 交付了原型却没走当时声明的主流程、没读依据文件，也没当场说，用户追问「基于哪个 skill」才知道。
• 不做八股：不介绍方法论来源，不列人名，不复述框架历史，直接给结论。
• ⭐ 内容准则：一切落盘文字都要先过「说人话」这一关（2026-10-07 用户定案，同日扩大到规则文件）。用户原话：「当作第一步 和 第二步 生成文档时 必须遵循的内容准则」「不管是写规则 还是 写文档 都要严格按照说人话的技能去执行」。
  • 适用面两类都算，只改产出不改规则等于半改。一是产出文档：research/1a-需求文档.md 到 1e-使用场景.md（5 份）、research/1b-独立分析/（独立分析体）、prd/2a-产品功能.md 与 prd/2b-界面布局.md（2 份）。二是规则本身：本技能包内的一切落盘文字，SKILL.md、references/**、模板与清单。
  • 判据来源（单一可信源，本文件不复述模式清单）：只有 humanizer 一份，且只用它的英文正式目录 —— <技能根>/humanizer/references/patterns.md 的 P1–P55（内容 8／语言与风格 10／沟通 3／填充与模糊 9／新兴 13／工艺与取证 12）。另有 5 种口吻档（casual / professional / technical / warm / blunt）。
  • 🔴 判据一律用英文目录（2026-10-15 用户令）：中文附录 patterns.zh.md（ZH1–ZH15）只作参考线索，⛔ 不作判据 —— 作者自标「实验性、未经中文母语写手校验、不应被当作已验证的规则」。原中文版 humanizer-zh 的 24 条与五维 50 分表随该技能删除一并停用作废。
  • 门槛（2026-10-15 改）： · 英文产出：可读 --score 的 0–100 AI 痕迹密度分（越低越像人；上游 pre-commit 的拦截线是 40），本包不设硬阈值，分数写进段末报告。 · 中文产出：⛔ 不采信自动分数 —— 该打分器按 [.!?] 切句、按 [a-z0-9] 切词，中文 。！？ 不切句、汉字零词，分数实际在测「文件里有多少拉丁字符」（实测：同一段中文把 。 换成 . 分数不变；零拉丁字符的中文直接判 No text）。改按 P1–P55 逐条人工对照，再跑 --check-facts 保真（它只抽数字／日期／版本／URL／路径／标识符，中文同形可用）。对照结果与事实存活数写进段末报告，命中项不对完不许落盘。
  • ⛔ 取不到判据来源时（2026-10-08 补）：两份技能都不在位或读不到 ⇒ 不许凭感觉判「这条够人话」。在段末报告与 3d-审查报告.md 里明写「无判据来源，本项未判」，按与 §供给·工艺数值判据 的「证据缺口」同一口径处理。
  • 五条核心原则（2026-10-15 起就地固化在本包；原引自已删除的 humanizer-zh《核心规则速查》，英文版 humanizer 的 Quick reference 没有等价条目，故不再指向外部）：删填充短语（开场白、强调性拐杖词）；打破公式结构（二元对比、戏剧性分段、修辞性设置）；变化节奏（长短交错，两项优于三项，段尾多样）；信任读者（直接陈述事实，跳过软化、辩解、手把手引导）；删金句（读起来像可引用的话，就重写它）。
  • 🔴 适用面要划清（2026-10-15 排查后立）：本包只取这份技能里**「去 AI 味」那一半**，⛔ 不取**「注入个性」那一半**。 取这些：英文模式目录 references/patterns.md 的 P1–P55、就地固化的五条核心原则、禁用清单。 不取这些：Soul Injection Techniques 整节（11 条）—— 它明写「有观点、别只报告事实」「用具体感官／体验细节代替抽象说法」「允许跑题与题外话」「结尾不必收束」「用 imperfect start 开场」，与本包产出要的客观书面说明文正好相反（照它写会出乱比喻、口水话、不能简明扼要）。该节第 3 条自带的示例就是「凌晨两点冷咖啡和看不懂的堆栈」这种感官化写法。 口吻档：本包产出固定取 technical（精确用词、一句一个意思、⛔ 无比喻除非确能澄清），⛔ 不用 casual／warm／blunt。 ⛔ 已停用：原中文版 humanizer-zh 及其五维 50 分表（该技能 2026-10-15 已整包删除，判据不再走它）。
  • 🔴 同一件事更严的那份说了算：④段的 references/doc-language-spec.md（客观书面说明文 ＋ 逐条禁用清单）是本包最严的一份语体规范；任一段落盘文字与它冲突，以它为准。
  • 交付留证：产出文档在段末报告里写明「已过内容准则，评分 X/50」；改规则文件时，在当日 memory 里记下这一关过了。
• 只调一段时不越界：用户说「只做第 N 段」，就跑该段，不展开其他段，也不用「你还没做调研」去催促。
• 提问上限 3 个：其余用合理假设，并在文档里标注 【假设】。例外是 grill-me 提问模式，不受此限（①段的「需求澄清」与②段的「需求压测」各一次），该模式的价值就是穷尽提问；此时须先声明「将连续多轮提问」，退出后恢复本约束。
• 反问优先，允许自动补全：grill-me 的默认动作是把问题抛给用户并附推荐答案。用户说「你定」、连续两轮不回应、或属事实类问题时，模型自行给答案并标 【假设】，换来「不卡住」；但每轮结束要汇出待复核清单，未经复核的 【假设】 不得在下游当事实用。
• 停线规则（单一真源，全包只在本节写一次，各段一律引用、⛔ 不复述）：只有三种情况停 —— ① 信息不足且查不到；② 破坏性／不可逆动作；③ 用户显式要求。
• MVP 边界优先：任何阶段都先回答「第一版做什么、不做什么」。
• 必须落盘：产出写入文件，不要只在对话里输出。
• 无来源就标注：任何查不到来源的数据都标为「估算」并写明口径，不编造数字当事实。
• 禁止长文：单份产出物默认一页纸（≤120 行），超长必须拆分。
• 🔴 路径写相对或占位（2026-10-14 用户令）：本包内一切文字（SKILL.md、references/**、脚本与注释、模板）引用本技能自己或同根技能的位置时，写相对形态 —— 同根技能写 <技能根>/<技能名>/，本包自己的文件写包内相对路径（如 references/stage-delivery/）。只有跨根引用（工作区根、文档库根、本机软件安装位这类从本包推不出来的别的根）才落到具体位置，且优先读环境变量（DSH_WS_ROOT / DSH_DOCS_ROOT / WORKBUDDY_BIN_ROOT）。原因：技能根的位置随环境变（全局技能根还是工作区技能根、用户名与盘符各不相同），写死了换台机器就是死路径，跨环境会整片报错。

征询外部模型（GPT）的提问口径（单一真源）

🔴 2026-10-15 用户令，逐字：「问 GPT 的时候 只需要说明 关键背景情况和需求询问，禁止带入过多细节上下问造成干扰」。本包内一切向外提问的动作都按本节写；③段 3c 的提问模板是本节的一个实例，⛔ 不在别处另立一套口径。

• 要写三样：① 场景一句（这是什么、要解决什么）；② 手上已有什么（只列与本次提问有关的）；③ 想问哪几个问题（逐条列，一条一个问点，末尾一句收口）。
• 判据：背景写到「对方能接住这个问题」为止 —— 少了这句，对方就问不出对的问题吗？问不出才留，问得出就删。
• ⛔ 不带：过程留痕、已废弃做法的设计细节、「我们为什么这么做」的来龙去脉、内部硬约束清单、字段与文件清单。这些会把回答拖进细节纠缠，占掉本该用在核心问题上的注意力。
• 为什么（避坑依据 · 2026-10-14 实测）：为问「原型说明文档该怎么写」，先铺了 1 500 余字的背景（含已废弃做法的 5 个设计点、4 条硬约束、7 个问题）⇒ 细节量压过问题本身。
• 留痕：提问原文与回答原文都要落盘；提问按本节写，⛔ 不把本机路径当内容（外部模型看不到本机路径，要么逐字内联、要么上传文件）。

产出文档开头必须有图（单一真源）

2026-10-15 用户令，逐字：「产品规划页面 所有文档前面都要画图」。各段一律引用本节，⛔ 不在段内另写一套口径。

• 每份落盘文档第一屏就给一张图：图放在标题之后、正文之前 —— 不读正文也能先拿到全貌。
• 图表达这份文档覆盖的东西之间的关系，按段定画什么： · ①段（research/ 五份）—— 画对象与流向：为谁解决什么、信息从哪来到哪去。 · ②段（prd/ 两份）—— 画页面骨架：有哪几页、每页几个板块、跨页关系怎么走。 · ③段（ui/ 下的产物与 DESIGN.md）—— 画页面结构与操作动线：用户办成一件事实际经过哪几页、每页做什么、哪里要来回跳。 · ④段（产品文档）—— 画用户路径：第一层轴那几段，以及每段四块（需求列表 → 用户场景 → 操作流程 → 功能）怎么串起来。
• 画图用 diagram-design，⛔ 不手写 Mermaid（判据见「工具选择规则」那张表）。
• 图里每格写清名字、线标方向；图与正文互相对得上 —— 正文新增或改了结构，图要跟着改，两处不许各说各的。

每段的标准收尾格式

## 本段结论
- （3-5 条，可直接决策的话）

## 已落盘
- ...

## 待确认（最多 3 条）

## 建议下一步
→ 用 <skill-name> 完成 <具体事>

反面清单

• 为一个小功能跑完整调研
• 输出长文却给不出一个结论
• 跳过「不做什么」
• 用户只问单点，却强行拉进全链路
• 把估算数据写成确凿事实
• 跳过③段 D0 的 Gate-1（未定死令牌表与设计契约）就开写页面代码
• 在 grill-me 提问模式下仍套用「提问上限 3 个」，把提问做成走过场
• 只跑一次 grill-me：①没定义需求就去取证，或②拿①段的需求定义代替功能压测直接写②段
• 把自动补全当默认动作：用户没说话就替用户拍板，还没标 【假设】、没进待复核清单
• 手写 Mermaid 代替 diagram-design，手写 token 表代替 DESIGN.md
• 绕过四段自己手搓，或重写它们的内容（该调 stage-* 就调）
• 把供给件的内部路径按本 skill 目录去拼，或改它们的正文 —— 供给件指③段自带的 oil-ui-pro，以及 §供给 各档落在 assets/ 下的件（它们是随③段携带的供给件，改动只写 stage-delivery 自己的 SKILL.md / references/；默认档与可选档平行，不缝成一条流水线，也不把 oil-ui-pro 的评分循环当成本段 Gate 的替代）
• 猜 <项目>：定不出来还硬写，把产物落到别的项目目录下
• 把 DESIGN.md 写到仓库根：多项目会互相覆盖
• 段间停下来问「要不要继续」：全流程（自动处理）模式下直接进下一段，只在段末输出报告
• 把两种模式混用：在自动处理模式下自作主张停下问方案，或在「方案确认」模式下确认前就开跑②③④
• 在「方案确认」模式下把①段的方案当成已确认就往下跑：该模式下①段末必须停下等用户确认（含「不做什么」）
• 下游擅自裁剪上游已拍板项：②③④发现要砍①段或决策表里已拍板的东西时，不许自行裁掉或改口径，必须列成「与已定决策的差异」交用户显式确认
• 把模式当成段：模式是「要不要在①段末停」的开关，不是第五个段，别为它单独造段或造产物
• 跑了却不说：没声明当前段 / 子步与依据文件，或偏离了被调 skill 的主流程却不声明、不记偏离单（应为：开工先声明、每个子步再声明、偏离当场声明）
• 让③段顺手把说明区或产品文档写了（那是第④段 stage-proto-doc 的活）
• ④段里重新规划产品、重新设计界面，或写原型上没有的页面 / 功能 / 业务规则（④段只解释与记录现有原型）
• 问外部模型时堆砌背景：把过程留痕、废弃做法、内部约束清单整段贴进去（应按「征询外部模型（GPT）的提问口径」只给关键背景 ＋ 明确问题）
• 落盘文档开头不给图，或图与正文各说各的（应按「产出文档开头必须有图」先上图、再写正文，两处对得上）
• 过「说人话」时把「注入个性」那半也照做：加观点、加第一人称、写感官细节与比喻、允许跑题（应按内容准则只取「去 AI 味」那半，产出仍是客观书面说明文）

改名 / 改供给后的自检

python scripts/check_naming.py --ws <工作区>

它查四段段名与子步名在「总入口 ↔ 各段 SKILL.md ↔ 各段 references/」之间有没有漂，包括 H1 与子步表是否一致、总入口子步列有没有漏项、runbook 必读表有没有引用已移除的资产、两份副本是否一致。纯静态比对，不需要渲染，不需要外部依赖。

为什么必须有它：实测当天漏过两次，当时没有任何门禁会报错。

第一次（2026-10-02）：改段名时 SKILL.md 改了，但 references/stage-discovery/references/grill-me.md 的 H1 仍写「需求澄清（grill-me · 调研段）」；references/stage-requirements/SKILL.md 子步表写「2b 功能流转」而正文 H2 写「## 2b 状态机」；总入口④段子步列只写「4a 说明区 / 演示引导」漏了 4b / 4c。三处都只能靠回读发现。

第二次（2026-10-06）：②段收窄为「只细化功能」（7 份产出变 1 份）后，各段 SKILL.md 都改了，但总入口的三处仍写着旧结构——四段表的②段子步列仍是「2a 功能定义与压测 / 2b 功能流转 / 2c 功能图示」，四段表的①段子步列「1c 产品定位与商业设计」未随段内改名（段内已改称「产品定位与场景」），正文仍写「①与②各跑一次 grill-me」并指向两份同名文档，实际全场只有①段一份。闸门当场报 6 个 FAIL，根因是「改了承载段、忘了总入口」。

由此立一条硬纪律，与「换供给不能只改承载段」同型：凡改子步结构 / 段内产出清单 / 段间交接口，必须连带改总入口 product-planning/SKILL.md 的「四段结构」表与「交接口」表，不改就是半改状态。

改了段名 / 子步名 / 判据供给源之后必须跑一次，并把结果记进当日 memory。改完不校验，下次读契约的人拿到的是错的配方。

本脚本只查文本一致性（H1 ↔ 子步表 ↔ 总入口 ↔ 副本），查不出「判据口径是否自相矛盾」。例如「②段到底该不该给页面结构」这种反转，闸门一个字都报不出来。口径类改动要靠人工回读，且必须把反转理由与用户原话写进文档留痕。

脚本输出里的 [提示] 项（旧名出现）不计入失败，但要人工看一眼是不是落在「废止理由块」里——落在里面是正当留痕，散落在正文里就是真残留。

2026-10-07 起本技能只在全局一份：技能根下的 product-planning/。它就是本体，不再有「主 / 副 / 装入」三副本，也不再需要「三处 md5 复核」（那只在有副本时才有意义）。改完只跑一次 check_naming.py --ws <工作区>。用户原话：「把产品规划复制到 workbuddy 全局skills中 后续维护和使用全局技能」。工作区原先那三份已归档到 归档/技能迁全局-20261007/（未直删，可随时取回）。