PPT image-first skill for Codex/Claude Code/Opencode CLI
Python
1,227
9 commits
updated May 8, 2026
中文 | English
一个 conversation-first、image-first 的 PPT 工作流 skill，用来把一个模糊的 PPT 需求，逐步推进成：内容基底、风格预览、定稿规划，以及后续可执行的生成流程。
ppt-image-first 不是那种一上来就让用户填一堆参数，或者直接套模板拼页面的 PPT skill。它更像一个分阶段推进的提案式工作流：先理解需求、补内容基底、出真实预览、允许反复推风格，最后再进入锁定与生成。
说明：输出方式是 image-first。 这套 workflow 默认使用 GPT Image 2 生成整页视觉图，再把这些页面图放入 PPTX 容器中交付；它不是直接用 PowerPoint 对象逐个绘制文字框、形状和图表的“完全可编辑 PPT”生成器。因此，成品更接近高完成度视觉稿式演示页：适合展示、汇报和继续做图像级 retouch，但页面内的文字、图形、装饰元素通常不能像原生 PPT 元素一样逐项编辑。
项目内已附一份直接用这套 workflow 做出来的介绍型演示稿，可直接下载查看：
这份文件的主题就是 ppt-image-first 本身，适合用来快速感受这套 skill 产出的页面风格、叙事组织和整体完成度。
它适合处理这类请求：
它的核心不是“快速出一个模板”，而是走一套完整流程：
content_report.md风格反演确认很多 PPT 工作流会在两个方向上出问题：
ppt-image-first 的目标就是同时避免这两类问题。
它的基本思路是：
用户被当成甲方，agent 被当成提出方向、生成方案、推进流程的设计侧。
这意味着：
这里的 preview 默认指 真实生成的图像预览，而不是：
最终生成也遵循同样逻辑：优先让 GPT Image 2 直接生成整页页面视觉，再封装进 PPTX；这能保持视觉完整度和风格一致性，但不承诺每个页面元素都是 PowerPoint 原生可编辑对象。
在 需求确认 之后，如果用户没有给出完整的报告式材料，就先生成一个 content_report.md 作为上游内容基底。
这样后面的：
design_spec.mdslide_blueprint.mdspec_lock.md都不是从空主题硬编，而是有真实内容来源。
它不会让用户直接在文字里选最终风格，而是先产出：
这三类预览，让用户看过再决定。
第一版完整结果出来后，不默认视为结束，而是进入专门的 review-and-retouch 流程。
只收集最必要的信息：
然后输出一个简短 baseline judgment，并停在 需求确认。
如果用户没有直接给出完整叙述内容，就先生成 content_report.md。
这个阶段的作用是：
只问 3 个短问题：
生成多套风格方向，并给出真实预览图，覆盖：
如果用户对某套方向基本满意但想继续调整，就从这一套继续往下推，而不是强迫立即定稿。
把用户最终选中的预览图当成“证据”，反推出用户真正喜欢的是哪些稳定特征，并区分：
按顺序生成：
design_spec.mdslide_blueprint.mdspec_lock.md然后进入 生成前确认。
先问用户是：
如果选多候选，就先进入 candidate picker，再进入最终 review。
默认用 review shell 做评审。
如果用户满意，就结束评审；不满意，就复制结构化反馈回对话继续返修。
这个 skill 自带 3 个固定工作流界面壳子：
assets/preview_shell/index.htmlassets/candidate_picker_shell/index.htmlassets/review_shell/index.html它们分别承担：
这些 shell 是工作流的一部分，不建议随意换成别的自制页面。
这个 skill 主要围绕 4 个产物推进：
content_report.md风格前内容基底。用于在用户材料不完整时，先形成一个能支撑后续 PPT 的小型报告化内容稿。
design_spec.md整套 deck 的全局理由、方向、连续性约束。
slide_blueprint.md逐页定义页面意图、内容 payload、视觉策略、承载重点。
spec_lock.md执行约束文件。用于锁定什么能改、什么不能改、哪些内容不能乱编、后续生成允许采用什么策略。
不是从固定模板页出发。
不是先让用户填一串设计参数表。
不是靠文字描述代替真正的风格预览。
当主题偏薄时，会先补内容基底，再出预览。
不会默认把生图只当背景，再靠后期乱补标题、数字、标签、说明框去“救”页面。
ppt-image-first/
├─ SKILL.md
├─ README.md
├─ README.en.md
├─ references/
│ ├─ workflow.md
│ ├─ conversation_framework.md
│ ├─ preview-flow.md
│ └─ ...
├─ templates/
│ ├─ content_report_reference.md
│ ├─ design_spec_reference.md
│ ├─ slide_blueprint_reference.md
│ └─ spec_lock_reference.md
└─ assets/
├─ preview_shell/
├─ candidate_picker_shell/
└─ review_shell/
这套 workflow 特别适合：
尤其适合这几种情况：
16:9，除非用户明确要求其他比例。本项目感谢 Linux.do 社区 对开源分享与传播的推动。
133 followers · starred Apr 2026
0 followers · starred Apr 2026
15 followers · starred Apr 2026
9 followers · starred May 2026
PPT image-first skill for Codex/Claude Code/Opencode CLI
Python
1,227
9 commits
updated May 8, 2026
中文 | English
一个 conversation-first、image-first 的 PPT 工作流 skill，用来把一个模糊的 PPT 需求，逐步推进成：内容基底、风格预览、定稿规划，以及后续可执行的生成流程。
ppt-image-first 不是那种一上来就让用户填一堆参数，或者直接套模板拼页面的 PPT skill。它更像一个分阶段推进的提案式工作流：先理解需求、补内容基底、出真实预览、允许反复推风格，最后再进入锁定与生成。
说明：输出方式是 image-first。 这套 workflow 默认使用 GPT Image 2 生成整页视觉图，再把这些页面图放入 PPTX 容器中交付；它不是直接用 PowerPoint 对象逐个绘制文字框、形状和图表的“完全可编辑 PPT”生成器。因此，成品更接近高完成度视觉稿式演示页：适合展示、汇报和继续做图像级 retouch，但页面内的文字、图形、装饰元素通常不能像原生 PPT 元素一样逐项编辑。
项目内已附一份直接用这套 workflow 做出来的介绍型演示稿，可直接下载查看：
这份文件的主题就是 ppt-image-first 本身，适合用来快速感受这套 skill 产出的页面风格、叙事组织和整体完成度。
它适合处理这类请求：
它的核心不是“快速出一个模板”，而是走一套完整流程：
content_report.md风格反演确认很多 PPT 工作流会在两个方向上出问题：
ppt-image-first 的目标就是同时避免这两类问题。
它的基本思路是：
用户被当成甲方，agent 被当成提出方向、生成方案、推进流程的设计侧。
这意味着：
这里的 preview 默认指 真实生成的图像预览，而不是：
最终生成也遵循同样逻辑：优先让 GPT Image 2 直接生成整页页面视觉，再封装进 PPTX；这能保持视觉完整度和风格一致性，但不承诺每个页面元素都是 PowerPoint 原生可编辑对象。
在 需求确认 之后，如果用户没有给出完整的报告式材料，就先生成一个 content_report.md 作为上游内容基底。
这样后面的：
design_spec.mdslide_blueprint.mdspec_lock.md都不是从空主题硬编，而是有真实内容来源。
它不会让用户直接在文字里选最终风格，而是先产出：
这三类预览，让用户看过再决定。
第一版完整结果出来后，不默认视为结束，而是进入专门的 review-and-retouch 流程。
只收集最必要的信息：
然后输出一个简短 baseline judgment，并停在 需求确认。
如果用户没有直接给出完整叙述内容，就先生成 content_report.md。
这个阶段的作用是：
只问 3 个短问题：
生成多套风格方向，并给出真实预览图，覆盖：
如果用户对某套方向基本满意但想继续调整，就从这一套继续往下推，而不是强迫立即定稿。
把用户最终选中的预览图当成“证据”，反推出用户真正喜欢的是哪些稳定特征，并区分：
按顺序生成：
design_spec.mdslide_blueprint.mdspec_lock.md然后进入 生成前确认。
先问用户是：
如果选多候选，就先进入 candidate picker，再进入最终 review。
默认用 review shell 做评审。
如果用户满意，就结束评审；不满意，就复制结构化反馈回对话继续返修。
这个 skill 自带 3 个固定工作流界面壳子：
assets/preview_shell/index.htmlassets/candidate_picker_shell/index.htmlassets/review_shell/index.html它们分别承担：
这些 shell 是工作流的一部分，不建议随意换成别的自制页面。
这个 skill 主要围绕 4 个产物推进：
content_report.md风格前内容基底。用于在用户材料不完整时，先形成一个能支撑后续 PPT 的小型报告化内容稿。
design_spec.md整套 deck 的全局理由、方向、连续性约束。
slide_blueprint.md逐页定义页面意图、内容 payload、视觉策略、承载重点。
spec_lock.md执行约束文件。用于锁定什么能改、什么不能改、哪些内容不能乱编、后续生成允许采用什么策略。
不是从固定模板页出发。
不是先让用户填一串设计参数表。
不是靠文字描述代替真正的风格预览。
当主题偏薄时，会先补内容基底，再出预览。
不会默认把生图只当背景，再靠后期乱补标题、数字、标签、说明框去“救”页面。
ppt-image-first/
├─ SKILL.md
├─ README.md
├─ README.en.md
├─ references/
│ ├─ workflow.md
│ ├─ conversation_framework.md
│ ├─ preview-flow.md
│ └─ ...
├─ templates/
│ ├─ content_report_reference.md
│ ├─ design_spec_reference.md
│ ├─ slide_blueprint_reference.md
│ └─ spec_lock_reference.md
└─ assets/
├─ preview_shell/
├─ candidate_picker_shell/
└─ review_shell/
这套 workflow 特别适合：
尤其适合这几种情况：
16:9，除非用户明确要求其他比例。本项目感谢 Linux.do 社区 对开源分享与传播的推动。
133 followers · starred Apr 2026
0 followers · starred Apr 2026
15 followers · starred Apr 2026
9 followers · starred May 2026