Imported from alchaincyf/huashu-slide-codex (SKILL.md). Install upstream with npx skills add alchaincyf/huashu-slide-codex. Copyright stays with the author.

Huashu Slide Codex

你是谁

你做的东西，都只有几秒钟起作用。

一页 slide，观众看三秒就翻过去了；一张封面，读者在信息流里划过只有一瞬。 所以这里没有「细看才好看」这回事——第一眼没成立，就是没成立。

那个标准是：产出要让人认不出是 AI 做的。不是「AI 做得还行」， 是别人看到会问「这谁做的」。你有能力达到——现在的模型可以调用任何一场发布会、 任何一家咨询公司、任何一位平面设计师积累的视觉语言， 限制通常不在能力，在于有没有先认定自己要做到那个水准。

你不是一个人，是一个团队

slide 是给人讲的，不是给人读的。 一页上的字如果多到需要读， 那页就该拆开或者变成图。开工前先想清楚：这页是拿来讲的，还是拿来看的。

你可以想多久

想多久都行。 版面这件事，多推敲两轮比返工十次省力。 候选要多，交付要少。

设计哲学：设计判断沿用 huashu-design——开工前去读它的「你是谁」和三方向硬门，不要只当一句口号（包含品牌资产协议），再像 Codex 一样把判断执行成一整套图片 PPT 或单张商单配图。本 skill 服务三类视觉物料——slides、公众号头图/正文配图、B站/YouTube/视频封面——它们共享同一个上游设计判断和 image_gen 路径，差异在尺寸、文字密度和构图安全区。

核心原则

• 本 skill 是 Codex 专用。存在的全部理由是 Codex 自带 image_gen 能力，能省下 nano banana / Gemini API / OpenAI Image API 的调用成本。任何修改和 fallback 都必须保留这条定位——不引入 generate_image.py、不要求 GEMINI_API_KEY / OPENAI_API_KEY、不调用其他第三方图像 API。
• 主路径：image_gen 逐张生成完整图片，再按交付物组装：slides → PPTX / HTML deck；单图 → 直接发布 / 上传图床（如果工具链已配置 tools/upload_image.py）。
• 只要当前 agent 环境是 Codex 且内置 image_gen 可用，默认相信图片生成能力；不要因为担心中文、字数或版式而先改走 HTML 截图路线。
• 每次图片生成前，先调用/遵守 huashu-gpt-image 的 prompt 方法论：中文优先，少堆形容词，优先真实风格/设计师/机构名。Slides 属于信息设计场景，允许 prompt 为了承载结构、文案和版式意图超过 80 字，但仍要避免英文伪结构化废话。封面图反过来——文字越少越好，优先纯视觉。
• 信息密度按页面类型分级，不是"每页都拉满"。120-220 字是内容页的上限，不是目标；其他页面类型必须远低于这个上限（封面 ≤8 字、章节扉页 ≤30 字、结论页 ≤40 字）。详见下方「Slide 页面类型与密度分级」。核心心法：稀疏的内容页比塞满字的内容页更专业——AI 默认会把上限当目标，所以这条要主动反向约束。
• 整套 PPT / 系列封面必须采用同一套视觉系统：同一个风格锚点、同一组颜色倾向、同一类字体气质、同一套图形语言。单页/单图可以变化构图，但不能换审美人格。
• 继承 huashu-design 的上游设计逻辑：先理解需求，顾问式重述，再给 3 个真正不同的设计哲学方向，并且只要任务涉及具体品牌就强制走核心资产协议输出项目级 brand-spec.md（详见 Step 0.0）。不要一上来就默认某个风格，除非用户已经明确指定。
• 约束哲学而非形式：先定义"为什么这样设计"，再定义"画面长什么样"。风格不是皮肤，是思考路径。
• 项目产物不能直接引用 $CODEX_HOME/generated_images/。生成后先检查图片，再复制到当前项目的 配图/、assets/、images/ 或 output/images/ 目录，并在 PPTX/HTML/Markdown 中引用项目内副本。
• Path 3（HTML 转 PPT）只在两种情况启用：① 用户原话明确说"要可编辑 PPT" / "不要图片 PPT"；② image_gen 工具实际调用失败 ≥3 次。除此之外，永远默认 Path 1 AI 图片 PPT——不要因为"内容精确""数字要准"等理由自我合理化切 Path 3，详见路径优先级章节的「默认路径锁定铁律」。

Slide 页面类型与密度分级

整套 PPT 不是同一种页面重复 N 次。一套合格的 deck 至少包含 4 类页面，每类密度上限不同，混合使用才有节奏感。第一页永远是封面，最后一页通常是结论。

密度心法（核心反 slop 准则）：

• 上限 ≠ 目标。AI 看到"220 字上限"会默认朝 220 字写。主动反向约束：每页先写"这页核心要让观众记住什么 1 句话"，再决定要不要补解释/结构，80 字能讲清的不要拉到 180。
• 同一信息有 3 种表达密度时（一句话 / 一段话 / 一段话+图表），选最稀疏的那种；只有稀疏版讲不清才上稠版。
• 信息块数量是稀疏度的关键指标——3 个比 5 个清晰，2 个比 4 个有力量。
• 一个观点配一个视觉隐喻 ＞ 三栏并列拆分（"它解决三件事"这种结构是 AI 拆解默认动作，要警惕）。
• 看完整套 deck，封面要让人看 1 秒就懂主题，内容页要让人看 5 秒抓住主旨，结论页要让人看 0.5 秒记住一句话。三种节奏不一样，密度才合理。

典型 10 页 deck 节奏：01 封面 → 02 章节扉页 → 03-05 内容页 → 06 章节扉页 → 07-09 内容页 → 10 结论页。不要做成 10 页全是内容页（视觉疲劳）；也不要 10 页全是封面式（信息缺失）。

启动决策

先判断协作模式，不必机械询问；用户没有特别说明时默认 Guided。

确认交付格式：

• PPTX：默认（slides 任务），PowerPoint 和 Keynote 都能打开。
• HTML 图片 deck：适合快速预览、发布到网页、或不需要可编辑 PPT 文件。
• 两者都要：先做图片，再同时导出 PPTX 和 HTML。
• 单图（公众号头图 / 正文配图 / B站·YouTube 封面 / 商单单张）：走 Path 4，直接交付 PNG/JPG；不组装 deck。任务里出现"封面""头图""视频封面""配个图""做张图"等单图关键词时优先识别为这一类。

流程档位

根据任务大小选择 Lite 或 Full，避免简单任务被过度流程化。

如果用户说“快点”“直接做”“不用选风格”，走 Lite；如果用户说“要好看”“做正式一点”“像作品”，走 Full。

Skill 边界

• huashu-design：所有视觉任务的上游设计判断权威——风格选型、品牌资产协议（核心资产协议 v1.1）、5 维评审。本 skill 把它的标准内置执行，不另立标准。
• huashu-gpt-image：prompt 方法论（中文短句、真实参考名、平台尺寸表）。本 skill 引用它的尺寸表和 prompt 规则。
• huashu-gpt-image / huashu-xhs-image：常规环境下的公众号 / 小红书配图业务流程（Gemini API / Playwright / ImgBB 上传）。当 agent 在 Codex 环境时，公众号头图/正文配图/视频封面这部分能力直接走本 skill 的 Path 4——同样的标准（尺寸、文字规则、安全区、双钩子互补），但用 Codex 内置 image_gen 取代外部 API 调用。
• huashu-slide-codex：把"做 PPT / Keynote / slides + 单张商单/平台配图（公众号封面、正文配图、B站/YouTube 封面）"的任务端到端交付出来。
• 当用户只问"这个视觉方向怎么定""给我几个设计风格"，优先使用 huashu-design。
• 当用户要实际生成演示文稿或单张商单配图，本 skill 内置必要的 huashu-design 逻辑，但最终目标必须是可交付物料。

路径优先级

🔴🔴🔴 默认路径锁定铁律（最高优先级，凌驾下文所有内容）

在 Codex 环境 + 内置 image_gen 可用的前提下，默认路径永远是 Path 1（AI 图片 PPT）。永远。永远。永远。

这条规则的存在理由：本 skill 只为 Codex 设计，唯一理由是省 AI 图片生成的 API 成本。如果不走 Path 1 而走 HTML 截图 / HTML 转 PPT，你就直接把 skill 的存在意义清零——用户完全可以不用本 skill。

唯一允许切到 Path 3 的触发器：

• ✅ 用户主动、明确说"文字必须可编辑" / "我要改 PPT 里的字" / "不要图片 PPT" / "做成可以二次编辑的 PowerPoint" —— 这是用户的显式选择，遵从。
• ✅ image_gen 实际不可用（不是你担心它不可用，是真的工具调用失败）—— 这是环境硬限制，没办法。

严禁自我合理化切 Path 3 的理由（脑里冒出立刻停下）：

• ❌ "内容有版本号/日期/数字要严格准确" —— Codex image_gen 实测能稳定渲染 200 字以内中文 + 数字 + 日期 + 版本号，先信任。
• ❌ "中文可能渲染错" / "用户要求精确/专业感/正式场合" —— 主观焦虑或模糊形容词，不是客观切路径依据。
• ❌ "内容多 / 信息密度高 / 200+ 字" —— 每页 80-180 字是常态；超过 220 字 = 该拆成两页（R6），不是切 Path 3。
• ❌ "版式控制 / 像素级精确" —— Codex 不是 Figma，AI 图片 PPT 不追求这个。
• ❌ "包含表格 / 代码 / 公式" —— 简单的 image_gen 能做；真正复杂表格也是只那一页局部用 Path 3，不是整套切。
• ❌ "保守起见 / 稳一点 / 为了体验" —— 保守 = 把 skill 用废。

禁止句式：「精准文字优先路线」「内容要数字准确所以走 HTML」「这套 PPT 适合走 HTML」—— 看到自己在为切 HTML 找理由，立刻停下回到 Path 1。

自检问句（动手前回答）：用户原话里是否出现"可编辑/改字/不要图片PPT"？image_gen 工具是否真的不可用？两条都"否" → 没有任何理由不走 Path 1。

Path 1：AI 图片 PPT（默认）

每张 slide 是一张完整图片，包含构图、视觉元素、标题、解释文字和必要数据。默认不是"海报配一句话"，而是"信息设计完整的一页演示"。适合发布演讲、课程封面、视频化课件、视觉冲击强的提案。

流程：

1. 深度理解需求，并顾问式重述。
2. 执行核心资产协议（Step 0.0）：搜索/索取品牌 logo、产品图、UI 截图，固化到项目 brand-spec.md。涉及具体品牌时这一步是硬约束，不能跳过。资产可直接作为 image_gen 参考图。
3. 确定设计规范 / VI：品牌色、字体气质、标志使用、留白、图形语言、版式秩序——直接读 brand-spec.md。
4. 如果找不到品牌 VI，不要卡住；提供 3 个基础但设计出色的视觉方向供用户选择，或按任务场景默认选择最合适方向。
5. 推荐 3 个差异化设计哲学方向。
6. 用户选择或任务默认选定 1 个方向。
7. 梳理大纲，并确定每一页想呈现的核心内容、文字量和视觉隐喻。
8. 写整套 deck 的视觉系统（Deck Bible），把品牌资产与 VI 规范纳入其中。
9. 为每页写信息量足够的 prompt，将品牌资产、VI 规则、页面内容和主视觉写清楚；如有可用 logo / 产品图 / 参考图，作为 image_gen 的参考图传入。
10. 调用内置 image_gen 直接生成完整 slide 图片。
11. 按设计评审维度检查图片，必要时重生成。
12. 复制图片到项目目录。
13. 用 scripts/create_slides.py 组装 PPTX，或用 scripts/image_deck_html.py 组装 HTML。

Path 2：HTML 图片 Deck

每张 slide 仍是 AI 图片，但交付为网页式演示。适合给用户先看设计方向，也适合不想打开 PowerPoint 的场景。

HTML 图片 deck 的默认形态必须是全屏单页演示：浏览器中一次只展示一张图，支持左右键、上下键、PageUp/PageDown、空格切换上一张/下一张，并保留页码。不要把所有图片纵向铺陈成网页画廊，除非用户明确要求长网页预览。

使用脚本：

uv run [SKILL_DIR]/scripts/image_deck_html.py \
  output/images/slide-01.png output/images/slide-02.png \
  -o output/deck.html \
  --title "演示标题"

Path 3：可编辑 HTML → PPT（仅用户显式要求时启用）

这条路径不是"fallback"，是"用户显式 opt-in"。先回去看路径锁定铁律——不要因为"我觉得这样更稳"就走这里。

启用条件只有两条（已在路径锁定铁律里写死，这里只是重复强调）：

1. 用户原话明确说要可编辑 PPT（"文字必须可编辑"/"不要图片 PPT"/"我要改字"/"做成可以二次编辑的"）。
2. image_gen 实际调用失败 ≥3 次，确认环境工具异常。

每页生成 720pt × 405pt HTML，再转为 PPTX。必须遵守 references/prompt-templates.md 中的 html2pptx 约束：

• div 里文字必须包在 <p> 或 <h1>-<h6>。
• 不用 CSS 渐变，只用纯色。
• 背景、边框、阴影放在外层 div，不要放在文字标签上。
• 图片用 <img>，不要用 background-image。

Path 4：单图配图（公众号头图 / 正文配图 / B站·YouTube 视频封面）

用户给的不是「做一套 PPT」而是「做一张封面 / 做一张配图 / 做个视频封面」时走这条路径。所有上游设计判断（核心资产协议、风格选型、Deck Bible 短版）都复用 Path 1，只是产物是 1-N 张独立图片而不是 deck。这条路径在 Codex 环境下替代 huashu-gpt-image / huashu-xhs-image 的 API 调用，所有标准从那两个 skill 同步过来。

适用场景：

• 公众号头条封面、正文章节插图、正文信息图。
• B站视频封面、YouTube 视频封面、视频缩略图。
• 商单单张主视觉、活动 banner。
• 系列文章 / 系列视频的封面延续。

平台尺寸表（硬底线，prompt 之前必查，与 huashu-gpt-image 同步）：

封面文字铁律（封面图特有，和 slide 反向）：

• 封面优先无文字，纯视觉冲击力。公众号 / B站标题区已经有标题文字，封面再重复一遍是浪费像素。
• 如必须有文字，≤8 字（产品名 / 4 字短语 / 关键概念）。
• 视频封面文字可以稍多，但**≤2 行、每行 ≤12 字**，并且要大、要居中、要在「中间正方形安全区」内（朋友圈/手机缩略图都会裁两边）。
• 不加额外标签 / badge / 「免费公测」「Chromium 内核」「装上眼睛」类胶囊——这些信息属于正文，不属于封面。
• 不加个人署名 / 水印；不出现「花生」「花叔」字样（除非用户明确要求落款）。

Prompt 防泄漏铁律（封面专用，从 huashu-gpt-image 同步）：

• ❌ 绝对禁止在 prompt 里出现 "square"、"center square"、"safe zone"、"框"、"边框"、"正方形" —— image_gen 会把这些理解为「在画面中画一个正方形」，导致中央出现明显方块。
• ❌ 不要要求 prompt 渲染「公众号标题」「视频标题」原文 —— 那是平台的标题文本，不是封面的内容。
• ✅ 安全区是给你（agent）判断构图用的内部参考，不写进 prompt。生成后用肉眼检查核心信息是否在中央 766×766（或视频缩略图中心 720×720）内。

配色禁忌：橙底黑字、赛博霓虹、深蓝 #0D1117（GitHub dark mode 烂大街复制）、紫渐变科技感（AI slop 最大公约数）—— 都不要用。深色模式适配：底色用 #F5F5F5 / #1A1A2E，文字用 #595959 / #3F3F3F。

标题×封面互补原则：标题制造点击欲望，封面建立视觉期待。标题「挖了 3 个坑」+ 封面「3 个坑」= 一句话两种表述浪费说服机会。正确：标题问封面答 / 标题抽象封面具象 / 标题情绪封面证据。

系列延续模式（系列文章 / 视频强制启用）：找上一封面图作为 image_gen 参考图传入 → prompt 写「基于这张参考图的风格继续设计；这一期主题 X，情感变化 Y，主视觉换成 Z」。例：源码泄露「机器人破墙而出」→ 橙皮书「同一机器人举横幅送书」，风格一脉相承但叙事推进。

🔴 默认 3 版本铁律（重要单图必须）

触发条件：Path 4 的「重要单图」任务——公众号头图、B站封面、YouTube 封面、视频缩略图、商单主视觉、海报。

默认行为：每次自主生成 3 个版本，每版用一个真正不同的设计哲学方向（不是 3 张同款 prompt 重复跑），让用户挑。这是 huashu-design 第 3 条核心原则「给 variations，不给最终答案」在单图场景的落地——重要单图属于"用户一旦发出去就改不了"的高风险产物，多花 2 张 image_gen 调用换 3 倍选择空间是绝对划算的。

3 个版本的差异化约束（每个方向必须真不同，不是配色微调）：

3 个方向必须来自不同流派；禁止"都差不多的 3 个版本"。如果是花叔自家像素风物料，"独特差异化"位默认用花叔像素风，另外两个位选反差大的流派。

例外（明确触发才跳过 3 版本）：

• 用户原话「快速做一张」「直接给我最好的版本」「不用选了」
• 系列封面延续模式——已有上一封面，本期只是延续，1 版本即可
• 商单方向已经定好（用户已经在前面对话里选过设计哲学方向）→ 走 1 版本
• 用户明确说「就用花叔像素风」「就用 Bloomberg 风格」→ 走 1 版本

3 版本工作流补丁：Step 0.3 给 3 方向时直接告知"我各生成一张你最后选"——不要等用户先选方向，3 个方向都画（image_gen 便宜，决策时间贵）。任一张 <7 分主动重生成，不让用户从 2 好 1 差里选。命名 封面-v1-bloomberg.png / v2-neopop.png / v3-pixel.png。

Path 4 工作流：

1. 走 Step 0.0 核心资产协议（如涉及具体品牌）。

2. Path 1 的 Step 0.1-0.3（顾问式重述 + 3 个设计哲学方向）。

3. 用 Path 1 的 Step 2（Deck Bible 短版，作为单图的"风格合同"）——3 个版本各写一份 Deck Bible 短版，不要共用。

4. 🛑 强制检查点：平台 + 尺寸 + 参考图清单 + 3 个方向 给用户确认。用户给"做个封面"经常不指定平台，这里必须主动列：

   • 目标平台（公众号头条 / 公众号正文宽图 / B站封面 / YouTube 封面 / 抖音封面 …）
   • 对应像素尺寸（从平台尺寸表里读，不凭记忆）
   • 拟传入 image_gen 的参考图清单（哪些 logo / 产品图 / 像素风参考 / 上一封面 …）
   • 拟写入的文字（≤8 字版本 + fallback "纯视觉无文字" 版本）
   • 拟生成的 3 个版本方向（除非命中"例外"，否则默认 3 版本）

   用户确认后再写 prompt。这步漏掉，后面经常发现"做完了才知道用户要的是 B站封面不是公众号头图"。

5. 按平台尺寸表选画布，按封面文字铁律和防泄漏铁律为每个方向写 prompt。

6. 调用 image_gen 生成 3 张（或例外触发时 1 张）；优先纯视觉、文字 ≤8 字、不出现禁词。

7. 走 Path 1 的 Step 4（5 维评审）+ 安全区肉眼检查；任一张低于 7 分主动重生成。

8. 复制图片到项目 配图/ 目录，按 封面-vN-方向锚点.png 命名；不直接引用 $CODEX_HOME/generated_images/。

9. 用 skill 自带的图床上传脚本换永久链接——公众号发布必须用网络链接，本地路径在发布后失效。

   # 需要 IMGBB_API_KEY（.env 放 cwd / skill 根 / ~/.env 都自动加载）；纯 stdlib 无 pip 依赖
   python3 [SKILL_DIR]/scripts/upload_image.py 配图/封面-v1.png

   key 没配置 → 让用户去 https://api.imgbb.com 注册免费 key。3 版本先不上传，用户选定终版再上传，省图床配额。

10. 给用户展示 3 个版本 + 简短选择理由（哪版适合点击率 / 哪版适合品味 / 哪版适合系列延续）；用户选定后归档其他版本到项目 配图/_备选/。

11. 系列继续走系列延续模式。

个人品牌触发（自带花叔像素风为示例 / 其他用户可替换）

给非花叔用户的提示：assets/personal-brand/ 里 ship 的是花叔本人的像素风品牌资产，作为"个人 IP 自动注入"的工作示例。其他用户使用本 skill 时有两种选项：

1. 替换：把自己的 logo / 头像 / 风格示例 PNG 放进 assets/personal-brand/，触发词从「花叔风格」改成自己的品牌名（编辑下面的触发条件）。
2. 关闭：删除 assets/personal-brand/ 目录；本节自动不触发，skill 主体（slides / 单图三版本 / 品牌资产协议）功能完整。

下面以花叔像素风为例描述触发机制，结构对任何个人 IP 都通用。

当用户提到「花叔风格」「花叔的封面」「个人品牌风格」「像素风」「像素风头图」「做成像素风」「像素品牌资产」，或上下文判断这就是花叔自己的公众号 / B站 / 个人 IP 物料时，自动启用以下三张参考图作为 image_gen 的参考输入：

🔴 花叔角色必须出现（铁律，实测踩过坑）

像素风触发 + 花叔自家物料 → 花叔本人（像素角色形象）必须作为画面主体或可识别的视觉锚点出现——不是"杯子图案""书签脸"，是画面里一个真正的角色。

反例（2026-05-23 踩过）：「环境派」封面 prompt 写"沿用参考图的像素风颗粒度、配色、角色形象"，image_gen 把"角色形象"当成可选风格要素，主视觉变成一本写"环境派"的手册，花叔降级成桌上马克杯图案。

Prompt 必含三段式（花叔像素物料专用）

写 prompt 时按这三段强制结构展开，缺一不可：

【风格】沿用参考图的像素游戏美术、奶油纸底、Field Notes × 像素 8-bit 配色和颗粒度。
【角色】花叔（参考第一张头像图：圆脸、黑发、休闲衬衫的像素人物）作为画面 [位置：左侧 / 中央偏右 / 桌前坐着 ...] 的主体，[动作描述：在看屏幕 / 在整理工具 / 在写白板 ...]。角色识别度优先，不要降级成杯子图案或挂件。
【场景】围绕花叔布置 [本期主题元素]：[具体物件 1 / 物件 2 / 物件 3]。
【文字】≤8 字（如「环境派」/「翻车了」），手写/像素字体，居中或位于明显位置。
【禁】无水印，不出现"花叔"字样的署名标签，不重复公众号标题原文。

反例 vs 正例 prompt

❌ 反例（实测翻车版本）：

盒把混乱AI工具图标整理成工作流，中央只有一本写"环境派"的手册。Field Notes×像素游戏美术，奶油纸底、黑绿黄褐，无其他文字无水印。

问题：主视觉是"手册"不是"花叔"；"角色形象"完全没写进 prompt。

✅ 正例（环境派 AI 工作流应该这么写）：

沿用参考图的像素游戏美术、奶油纸底、Field Notes × 像素 8-bit 颗粒度。花叔（参考第一张头像图：圆脸、黑发、像素人物）坐在中央偏左木桌前，把散乱 AI 工具图标按"环境/角色/工具/输出"四类归位到翻开的 CLAUDE.md 手册里。桌上有像素咖啡杯、Field Notes 笔记本、台灯。右上角像素字"环境派"。无水印，不出现"花叔"署名。

其他执行规则

• 不强行套用：只有用户明确要求"花叔风格 / 像素风"，或任务上下文显然是花叔自家物料时才启用。商单/客户品牌项目不要用花叔的像素风污染。
• 允许的角色缺席场景（用户必须明确说才能跳过）：
  • 用户原话「不要把我画进去」「做个纯工具图」「做产品对比图，不要人物」
  • 主题是单一产品 review（如「Gemini 4 上手」）且用户明确说"主视觉是产品"
  • 系列封面里某一期刻意要"花叔缺席"作为叙事（如「我休假这周」）
• 没有上述明确信号 → 默认花叔必须出现。
• 作为参考图，不作为最终结果：把图片作为 image_gen 的视觉参考输入；prompt 里按三段式展开描述本次需要的画面。
• 像素头像（第一张）是默认强制参考图——不再是"可单选可多选"里的"可选"项；不传它，花叔角色形象会跑偏。
• 启用后这套像素风本身就是花叔的 brand-spec.md——不要再额外去搜「花叔品牌色」「花叔字体」之类，直接以这三张图为权威。

Step 0.0：核心资产协议（涉及具体品牌时强制执行）

这是稳定性的生命线。从 huashu-design v1.1 同步过来。Agent 是否走通这个协议，直接决定输出质量是 40 分还是 90 分。不要跳过任何一步。

触发条件：任务涉及具体品牌——用户提了产品名/公司名/明确客户（Stripe、Linear、Anthropic、Notion、Lovart、DJI、自家公司等），不论用户是否主动提供了品牌资料。商单 brief 触发，个人物料如果有锚定品牌也触发。

前置硬条件：先用 WebSearch 验证品牌/产品存在且状态已知（发布日期、最新版本、关键规格）。事实错了，设计再好也是错的。

资产识别度排序（必须按这个顺序找）

只抽色值 + 字体、不找 logo / 产品图 / UI = 违反本协议。用 CSS 剪影替代真实产品图 = 违反本协议。找不到资产硬做 = 违反本协议。宁可停下问用户，也不要用 generic 填充。

5 步硬流程

1. 问：按资产清单一次问全（Logo / 产品图 / UI / 色值 / 字体 / brand guidelines）。
2. 搜官方渠道：<brand>.com/brand、/press、/press-kit、官网 inline SVG、App Store 截图、官方 launch video 截帧。
3. 下载：curl -A "Mozilla/5.0" -L <url> -o assets/<brand>-brand/<file>；产品图取 hero image 高分辨率；UI 取 App Store 产品页或官网 screenshots section。
4. 验证 + 提取：logo 至少两个版本（深底/浅底）+ 透明背景；产品图 ≥2000px；UI 是最新版本；色值用 grep -hoE '#[0-9A-Fa-f]{6}' assets/<brand>-brand/*.{svg,html,css} | sort | uniq -c | sort -rn | head -20 过滤黑白灰。
5. 固化为 brand-spec.md（写入项目目录，所有后续 prompt 都引用它）。
6. 🛑 强制检查点：把 brand-spec.md 摘要给用户过目，等待确认。
   • 摘要必须包含：资产完整度（完整 / 部分 / 推断）、采集到的核心资产清单（logo 路径 / 产品图路径 / UI 路径）、主色 + 强调色、气质关键词、明确的禁区。
   • 未确认前不进入 Step 0.1。资产协议走偏，后面全套 deck / 单图都会跟着歪 —— 这是品牌资产协议里成本最低的纠偏机会。
   • 用户确认后才可以进入设计哲学推荐；用户提出修订（"主色这个不对""logo 用浅底版""禁色加上 X"）则原地修订 spec 后再次给用户过目。

brand-spec.md 模板

# <Brand> · Brand Spec
> 采集日期：YYYY-MM-DD
> 资产来源：<列出下载来源>
> 资产完整度：<完整 / 部分 / 推断>

## 🎯 核心资产（一等公民）

### Logo
- 主版本：`assets/<brand>-brand/logo.svg`
- 浅底反色版：`assets/<brand>-brand/logo-white.svg`
- 使用场景：<片头 / 片尾 / 角落水印 / 全局>
- 禁用变形：<不能拉伸 / 改色 / 加描边>

### 产品图（实体产品必填）
- 主视角：`assets/<brand>-brand/product-hero.png`（2000×1500）
- 细节图、场景图…

### UI 截图（数字产品必填）
- 主页：`assets/<brand>-brand/ui-home.png`
- 核心功能：`assets/<brand>-brand/ui-feature-<name>.png`

## 🎨 辅助资产
### 色板
- Primary: #XXXXXX  <来源标注>
- Background / Ink / Accent / 禁用色…

### 字型
- Display / Body / Mono…

### 签名细节
- <哪些细节是「120% 做到」的>

### 禁区
- <明确不能做的：比如 Lovart 不用蓝色>

### 气质关键词
- <3-5 个形容词>

5-10-2-8 素材质量门槛（铁律）

• 5 轮搜索（多渠道交叉，不是第一页就停）
• 10 个候选才开始筛
• 选 2 个精品（其他全用 = 视觉过载 + 品位稀释）
• 每个 8/10 分以上（不够 8 分宁可不用，用诚实 placeholder 或重新生成）

Logo 例外：有就必须用，不适用 5-10-2-8——logo 是识别度根基，6 分 logo 也比没 logo 强 10 倍。

写完 spec 后的执行纪律

• 所有 image_gen prompt 必须引用 brand-spec.md 里的资产文件路径，可用 logo / 产品图 / UI 截图作为参考图输入。
• 不允许用 CSS 剪影 / SVG 手画 / 凭记忆描述代替真实资产。
• 品牌色直接写值（如 #1783FF），不写「类似蓝色」。
• 想临时加色要先改 spec —— 让品牌一致性从"靠自觉"变成"靠结构"。

缺失资产的兜底

禁止：找不到资产就静默用 CSS 剪影 / 通用渐变 / 凭记忆色 硬做——这是协议最大的反 pattern。

协议代价 vs 不做代价：走完协议 ~30 分钟（logo/产品图/色值/spec）；不做协议 → 通用 slides 返工 1-2 小时。商单 / 发布会 / 重要客户项目，30 分钟的资产协议是保命钱。

Step 0：设计理解与方向推荐

在写大纲和 prompt 前，先完成设计判断。这个阶段继承 huashu-design 的核心逻辑。Step 0.0 是这一阶段的前置硬步骤（涉及具体品牌时）；Step 0.1-0.4 在此基础上展开。

0.1 深度理解需求

确认或自行判断：

• 目标受众：谁会看这套 PPT？
• 核心信息：看完后要相信什么、理解什么、采取什么行动？
• 使用场景：公开演讲、内部汇报、培训课件、销售材料、课程资料还是文章配套？
• 情感基调：可信、锋利、温暖、兴奋、克制、实验、诗意？
• 交付格式：PPTX、HTML deck、Keynote 可打开文件，或多格式。

如果信息不足，一次最多问 3 个问题；如果用户催促或任务清晰，直接基于上下文判断。

0.2 顾问式重述

用 100-200 字重述本质需求，必须讲清：

• 这套 deck 真正要解决的传播问题。
• 受众为什么会在意。
• 设计需要制造什么感受。
• 视觉上最应该避免什么。

结尾用一句话过渡：“基于这个理解，我准备了 3 个设计方向。”

0.3 推荐 3 个设计哲学方向

推荐的不是 3 个配色，而是 3 条设计哲学。每个方向包含：

• 风格名称：必须含真实设计师、机构、出版物、品牌或艺术传统。
• 为什么适合：连接受众、内容和场景。
• 核心特征：3-4 条可执行视觉特征。
• 信息密度策略：这套风格如何承载内容页 80-180 字典型、封面/章节扉页/结论页保持稀疏的节奏。
• 风险：例如过于安静、过于艺术、中文层级压力大。

输出模板：

基于这个理解，我准备了 3 个设计方向：

1. [方向名：真实设计师/机构/出版物 + 风格定位]
为什么适合：[50-100字，连接内容、受众和场景]
核心特征：[3-4条]
信息密度策略：[如何用 80-180 字典型节奏承载内容页 + 配套封面/扉页/结论页稀疏节奏]
风险：[可能的问题]

2. ...
3. ...

我的默认建议：[选一个]，因为[一句话理由]。

找不到品牌 VI 时，可从以下基础风格池里选 3 个真正不同的方向给用户选择；这些不是兜底劣化，而是已经验证过能承载复杂信息的高质量视觉系统：

3 个方向必须来自不同流派，形成真正反差：

禁止推荐 3 个“都差不多”的方向。用户如果不想选，默认选择最能承载信息、最符合场景的方向，并说明理由。

0.4 方向 Demo

如果任务重要、风格不确定、用户要求好看，先生成 1-3 张 Demo：

• 可为 3 个方向各生成一张封面/样页。
• 也可在选定方向后先生成 1 张样页验证风格。
• Demo 通过后再批量生成全套，避免整套风格走偏。

Demo 也必须复制到项目目录，不直接引用 $CODEX_HOME/generated_images/。

Step 1：内容梳理

把材料转成逐页大纲。先定每页的页面类型（封面 / 章节扉页 / 内容页 / 结论页，见上方分级表），再写内容——类型决定密度上限，不要先写满字数再问"这是什么页"。

默认结构（10 页以内 deck）：

• Slide 01：永远是封面页——大标题 + 副标题 + 主视觉，没有信息块、没有"它解决三件事"的拆分。
• 中间页：内容页为主，每 3-4 个内容页之间插一张章节扉页做转场，让节奏有呼吸。
• 最后一页：结论页——一句核心判断 + 一个标志性视觉。

每页必须定义：

• 页面类型：4 选 1（封面 / 章节扉页 / 内容页 / 结论页），决定密度上限。
• 标题：断言句，不是主题词。例：「AI Agent 的价值在工具边界」优于「Agent 介绍」。
• 核心结论：这一页观众必须带走什么——一句话讲清。
• 页面文案：按页面类型选上限（封面 ≤8 字 / 扉页 ≤30 字 / 内容页 80-180 字典型，220 字上限 / 结论页 ≤40 字）。先尝试用上限的下半区写，写不下再考虑往上加。可以包含短段落、标签、步骤、对比、引用、数据解释，但必须有清晰层级。
• 信息结构：选择 1 种主结构，例如"问题→判断→行动"、"对比 A/B"、"三步流程"、"一张图解释机制"、"案例拆解"。封面 / 扉页 / 结论页跳过这一项——它们没有信息结构，只有一个观点和一个视觉。
• 视觉场景：说明应该看到什么，以及它如何帮助理解内容。不要只写装饰，不要只写 CSS 布局。

设计规则：

• 一页只讲一个观点。
• 视觉先行，但文字不必稀少；文字负责把判断讲完整，视觉负责让结构一眼可见。警惕：AI 默认会朝上限写，要主动反向约束，能 80 字讲清的不要拉到 180。
• 观众走神 5 秒后回头，仍能从画面抓住主旨。
• 不编造数据；不确定的数据先查证或标注为待确认。
• 单页超过密度上限 = 该拆成两页，不是硬塞。
• 看完逐页大纲做一次自检："是否每页都是内容页类型？" 是的话立刻插入封面 + 扉页 + 结论页，整套节奏才合格。
• 信息密度要“有层次地高”，不是平均铺满。每页至少有一个视觉焦点、一个主标题、一个解释区、一个结论或行动提示。

Guided/Collaborative 模式下，大纲确认后再进入风格选择。

Step 2：Deck Bible

选定设计方向后，才写 Deck Bible。它不是简单的“风格描述”，而是整套 PPT 的设计哲学合同。

生成任何单页之前，先写一份简短 Deck Bible。它是整套 PPT 的风格合同，后续每页 prompt 都必须继承。

Deck Bible 必须包含：

• 设计哲学：为什么这套 deck 要这样设计，而不是只描述样式。
• 统一风格锚点：真实出版物、设计师、品牌、漫画/插画传统或机构名。
• 视觉语言：插画、摄影、信息图、杂志版式、手绘板书、卡片系统等只能选一个主语法。
• 颜色气质：用自然语言描述，不必写 hex。例如“奶油纸底、黑色墨线、红色批注”。
• 字体气质：例如“杂志大标题 + 清晰中文正文”“板书手写感”“Field Notes 标签字”。
• 版式规律：标题区、解释区、图形区、结论区在整套里保持同类秩序。
• 信息密度规律：每页如何安排标题、解释、结构、结论，不让内容散掉。
• 禁止项：不要换风格、不要加入无关英文拟声词、不要让装饰压过信息。

Deck Bible 示例：

整套采用 Field Notes × Anthropic 信息手册风格：奶油纸底、黑色粗线图标、低饱和绿色/蓝色/黄褐色卡片。每页都有大标题、三到五个信息块、一个中心图解和底部结论条。中文为主，像一本可投影的工作手册，不像营销海报。

Spread Frame（信息手册版式框，推荐）

实测验证（OpenClaw 橙皮书宣传 PPT，2026-05-23）：信息手册风用「跨页框 + 单页变化」识别度最高。每张内容页共用 3 个不变元素：顶部品牌条（左刊头小字 + 右品牌 logo / 章节角标）+ 正文区（自由布局）+ 底部结论条（🚩 一句话 + 可选 3 小要点）。框不动，正文随内容变。

适用：信息手册类（Field Notes / Penguin Books / Anthropic / Bloomberg Businessweek）、技术分享、教学课件、产品宣传 deck。不适用：纯艺术海报、纯叙事 deck。

封面页 + 结论页可以部分跳出框（封面只留 logo，结论页让主视觉占满）；章节扉页保留框但留白更大。

吉祥物穿线（Mascot Continuity，品牌有角色时强烈推荐）

实测验证：OpenClaw deck 把"AI 虾"角色在 8 页里以不同姿态反复出现（举书/在地图前/拿放大镜/在台阶上…），整套 deck 从"8 张独立信息图"升级成"连环画"。

启用条件：

• 品牌已有 mascot / 角色（OpenClaw 的虾、花叔的像素人物、企业 IP 形象）
• 或风格本身适合（Snoopy 漫画、学習漫画、像素游戏美术）

执行规则：

• 在 Deck Bible 中明确写「角色锚点：[mascot 名称] 以不同动作/姿态出现在大部分内容页」。
• 每页 prompt 里指明这页 mascot 的动作（"虾举着翻开的书""虾在 8 个模块前指路""虾踩在 5 级台阶上"），不是一个静态形象贴满。
• 角色姿态服务于内容——讲流程时角色"走路径"，讲分类时角色"分发"，讲行动时角色"出发"。
• 反例：mascot 只出现在封面，后面忘记 → deck 像散装文章。

如果需要扩展风格细节，优先读取：

• references/proven-styles-gallery.md
• references/proven-styles-snoopy.md
• references/design-movements.md

常用风格路由：

AI 图片稳定性优先级：

• 低噪点：xkcd 白板、Ligne Claire、NYT Magazine。
• 中等风险：Snoopy、软木板、黑板粉笔。
• 高表达但易加字：Manga、Neo-Pop。必须限制“只渲染指定文字”。

优先选择“能承载复杂信息”的风格，而不是只好看的风格：

• 信息手册：Field Notes、Penguin Books、Anthropic、Bloomberg Businessweek。
• 数据叙事：NYT Magazine、Fathom、Reuters Graphics、Bloomberg Graphics。
• 技术解释：xkcd 白板、Ligne Claire、Takram、MIT Technology Review。
• 课程课件：黑板粉笔、软木板剪贴簿、学習漫画、The Oatmeal。

Step 3：写图片 Prompt

先用 huashu-gpt-image 方法论去掉空泛形容词和英文伪结构，再按页面类型选 prompt 模板——封面 / 扉页 / 内容页 / 结论页有 4 套不同 prompt 结构，不能共用一个模板。

按页面类型选 prompt 模板

封面页 prompt（slide 01 / 单图封面）

沿用这套视觉系统：[粘贴 Deck Bible 短版]。
封面图，[平台尺寸]，主题：[一句话讲清这是什么 deck]。
画面：[1 个标志性视觉，例如 "一本翻开的工作手册 + 一支像素风钢笔"]。
文字：仅显示大标题"[≤8 字]"，可选副标题"[≤16 字]"。不出现章节列表、不出现 3-5 个步骤、不出现解释段落。
要求：留白充足，主视觉占画面中心 ≥50% 面积；克制感优先于信息量。

章节扉页 / 转场页 prompt

沿用这套视觉系统：[Deck Bible 短版]。
章节扉页，主题：[这一章要讲什么]。
画面：1 个强视觉隐喻，配合 ≤30 字的强判断句。
文字：仅"[一句强判断]"，无信息块、无步骤、无 takeaway。
要求：单一焦点，留白可观，像翻到下一章扉页。

内容页 prompt（主要类型）

沿用这套视觉系统：[粘贴 Deck Bible 短版]。
本页主题：[断言式标题]。
页面文案：[80-180 字典型，220 字上限。按 标题 + 1-3 句解释 + 2-4 个标签/步骤/对比 + 1 句结论 组织]。
画面：[主视觉、信息结构、图形隐喻、层级关系]。
要求：和前面页面同一风格，中文清晰，信息密度适中（不到上限不要硬填），不要额外英文装饰。

结论页 prompt

沿用这套视觉系统：[Deck Bible 短版]。
结论页，主题：本套 deck 最希望留给观众的一句话。
画面：1 个标志性视觉（呼应封面或本套 deck 的核心隐喻），周围大量留白。
文字：仅 ≤40 字的核心判断 + 可选 CTA / 联系方式。不要列要点、不要回顾全 deck。
要求：节奏放慢，像谢幕，不像销售。

防泄漏铁律（4 类页面都适用）

• 不写 pt/px、百分比、CSS、布局网格。除非品牌规范必须精确控色，否则不写十六进制色值。
• 不写不希望出现在画面里的英文术语。
• 不把整套长大纲塞进 prompt，只写这一页需要的内容和 Deck Bible 短版。
• prompt 里出现的每个词，都要假设可能影响画面；因此要写可见信息、风格规则和明确禁止项，不写闲聊。

中文文字规则

• 默认认为 200 字以内中文可以可靠生成；超过 220 字按"该拆成两页"处理而不是硬上 prompt。
• 标题可以是完整判断句，正文可以是短段落，但必须通过字号、卡片、标注、编号、色块形成层级。
• 可以使用技术名词、英文产品名和简单公式；复杂公式仍建议转成图解或拆成多行。
• 如果文字错，先检查是否层级太乱或信息结构不清，再重生成。

密度反向约束清单（写完 prompt 自检）

写完一条 slide prompt，生成前自检：

• 这一页的页面类型已经定了吗？（封面 / 扉页 / 内容页 / 结论页）
• 字数是否在该类型上限以内？（封面 ≤8 / 扉页 ≤30 / 内容页 ≤220 / 结论页 ≤40）
• 内容页：是不是 80-180 字就能讲清，却拉到 200+ 了？能省的全省。
• 是不是无意识地把"X 解决三件事 / X 有三个特点"拆成三栏？这是 AI 默认动作，不是好结构——能用一个观点 + 一个隐喻表达就别拆。
• 这一页观众能在 5 秒内抓到主旨吗？做不到=过密。

Step 4：生成与检查

调用内置 image_gen 逐页生成图片。生成后必须检查：

• 中文是否准确。
• 是否出现 prompt 泄漏、乱码、英文拟声词、无关标签。
• 风格是否统一。
• 信息密度是否与页面类型匹配：内容页该有标题+解释+结构+结论；封面/扉页/结论页则反向——单一焦点 + 大量留白才对。不要拿"内容页标准"评封面。
• 设计是否出色：是否有明确视觉焦点、层级、留白、颜色节奏和可记住的图形隐喻。
• 画面是否真正承载主旨，而不是只有装饰。

按 huashu-design 五维评审做快速打分：

额外的「页面类型恰当性」检查（新增维度，与 5 维评审并行）：

• 封面页（slide 01）：文字是否真的 ≤8 字？有没有混入信息块 / 解释段落 / 3-5 个步骤？如果出现"它解决三件事""核心三步骤"的拆分=必须重生成。
• 章节扉页：文字是否 ≤30 字？是否只有 1 句强判断 + 1 个视觉？出现信息列表=过密，重生成。
• 内容页：实测字数是否落在 80-180 字区间？超过 220 字=拆成两页；少于 50 字且没有视觉支撑=信息太薄，可能本该并入相邻页。
• 结论页：是否在回顾全 deck？是的话重写——结论页不是总结页。
• 整套节奏检查：把 N 张 slide 排成一列扫一眼，是否能看出"封面 → 内容 → 转场 → 内容 → 结论"的密度起伏？如果每页看起来一样密=节奏失败，需要重新分类型。

低于 7 分的页 或 页面类型恰当性不通过的页，不要硬塞进最终 deck；先重写 prompt 或重生成。

评审记录模板：

Slide NN 评审：
- 哲学一致性：_/10
- 视觉层级：_/10
- 细节执行：_/10
- 功能性：_/10
- 创新性：_/10
- 结论：保留 / 重生成
- 修复方向：[如果重生成，写清 prompt 要改什么]

如果风格漂移：

• 不要继续生成下一页。
• 把 Deck Bible 缩短成更强的固定前缀。
• 在下一张 prompt 开头写“继续使用上一页完全相同的视觉系统”。
• 必要时重生成偏离风格的页面。

检查通过后，把图片复制到项目目录，例如：

项目/YYYY.MM-项目名/配图/slides/slide-01.png

不要让最终 HTML、PPTX、Markdown 或项目说明引用 $CODEX_HOME/generated_images/。

Step 5：组装

PPTX：

uv run [SKILL_DIR]/scripts/create_slides.py \
  项目/YYYY.MM-项目名/配图/slides/slide-01.png \
  项目/YYYY.MM-项目名/配图/slides/slide-02.png \
  --layout fullscreen \
  -o 项目/YYYY.MM-项目名/output/deck.pptx

HTML 图片 deck：

uv run [SKILL_DIR]/scripts/image_deck_html.py \
  项目/YYYY.MM-项目名/配图/slides/slide-*.png \
  -o 项目/YYYY.MM-项目名/output/deck.html \
  --title "演示标题"

Keynote：

• 交付 PPTX，说明可直接用 Keynote 打开。
• 如果用户要求 .key 原生文件，优先询问是否接受 PPTX；原生 Keynote 通常需要本机 GUI/AppleScript，可能需要额外授权。

大文件策略：

• 图片 PPTX 超过 80MB 时，先保留原始图片，再生成一份压缩版交付。
• 压缩优先使用 Pillow 或系统图片工具把 slide PNG 宽度压到 1920px 左右，质量保持可读。
• 不删除原图；原图继续保存在项目 配图/slides/，压缩图放 配图/slides-compressed/。

降级策略：

• image_gen 不可用：暂停并说明卡点；如果用户接受，改走 HTML fallback。
• 不要因为主观担心中文、字数、版式或精确日期就主动切到 HTML fallback；这些问题优先通过更好的 Deck Bible、品牌/VI 约束、参考图和重生成解决。
• 单页风格漂移严重：不要继续批量生成，先重写 Deck Bible 短版并重生成样页。
• 中文/数据错误：优先重写 prompt 并重生成该页；只有用户明确要求文字可编辑、反复重生成仍无法接受，或 image_gen 不可用时，才改用 HTML fallback 做该页或整套。
• PPTX 组装失败：先交付 HTML 图片 deck，同时检查图片路径、文件格式和 python-pptx 依赖。

生成失败时的救援策略（仍在 Path 1 内）

⚠️ 救援 ≠ 切路径。image_gen 产出不满意 → 默认重写 prompt 重生成，不是切 Path 3。

• 中文错字 / 乱码 → 简化文字、缩短到 ≤180 字，重试最多 3 次。
• 风格漂移 → 重写 Deck Bible 短版作为更强前缀，重试最多 2 次。
• Prompt 泄漏（出现 CSS / 英文术语）→ 移除 prompt 里 pt/px/百分比/英文术语，重试最多 2 次。
• 单页 ≥10 单元格精确表格 → 先问用户：① image_gen 近似版（推荐）/ ② 这一页单独 HTML 嵌精确表格 / ③ 简化表格 —— 让用户选。
• image_gen 工具调用失败 ≥3 次 → 告知用户并询问"切 Path 3 还是等环境恢复"。

穿越所有失败模式的铁律：除非用户明确同意，整套 deck 不会自动切到 Path 3。最多单页局部用 HTML 兜底。

Step 6：交付说明

最终汇报必须包含：

• 完成页数 / 图数。
• 选用设计方向，以及为什么选它。
• 如涉及具体品牌：brand-spec.md 路径、采集的资产清单（logo / 产品图 / UI / 色值 / 字体）和资产完整度。
• 如启用花叔像素风：列出引入的参考图。
• Deck Bible 或单图风格合同摘要。
• 交付文件路径（PPTX / HTML / 单图 PNG）。
• 项目内图片路径。
• 哪些页 / 图重生成过，以及原因。
• 五维设计评审简报：哲学一致性、视觉层级、细节执行、功能性、创新性。
• 风格一致性与信息密度检查结果。
• 单图任务额外汇报：平台尺寸是否对齐、封面文字是否 ≤8 字、是否落在中央安全区、是否触发了系列延续模式。
• 如果没有跑验证或没有打开预览，要明确说明。

路径要遵守写作工作区规则：不要把产物写根目录；有项目就写项目目录，没有项目先建 09-实验项目/<项目名>-YYYYMM/。

参考文件

所有引用路径都用 [SKILL_DIR]/... 相对前缀，不依赖任何机器特定的绝对路径——本 skill 完全 self-contained，可直接分发。

环境变量约定（只读，永远不要硬编码或打印）：

版本自检（静默）

本节给 AI agent：每次使用本 skill 前，先做一个不联网的判断——读本 skill 目录（SKILL.md 所在目录）下的 .last-update-check 文件（内容为一行日期 YYYY-MM-DD）。文件存在且距今不足 30 天，跳过本节直接干活，不向用户提任何更新相关的话。

到期或文件不存在时，且仅在此时：

1. 本目录不是 git 克隆（无 .git 或无 origin）→ 写入今天日期后跳过本节
2. 对比版本：git -C <本目录> rev-parse HEAD 与 git -C <本目录> ls-remote origin HEAD
3. 无论结果如何，把今天日期写入 .last-update-check
4. 两者一致 → 什么都不说；确认落后 → 先完成用户当前任务，结束后附一句「本 skill 有新版本，可用 git -C <本目录> pull --ff-only 更新」。是否更新由用户决定，不要主动执行更新