codex-ppt

name	codex-ppt
description	从文章、报告、论文、笔记或大纲生成视觉统一的全页图片式 PPT/PPTX 演示文稿；适合需要强视觉风格、统一版式和可直接汇报的 slides。
metadata	{"openclaw":{"requires":{"bins":"[Truncated]"},"primaryEnv":"OPENAI_API_KEY","envVars":["[Truncated]","[Truncated]","[Truncated]","[Truncated]"],"homepage":"https://github.com/ningzimu/codex-ppt-skill"}}

Codex PPT

Overview

This skill creates image-based PowerPoint decks from source material. Each slide is a complete 16:9 generated image. Final images are assembled into .pptx with scripts/assemble_ppt.py.

Use this when the user wants a visually unified presentation and accepts full-slide image pages. Do not use it when every textbox, chart, or shape must remain separately editable.

Prefer the built-in image generation/editing tool. Use scripts/image_gen.py only when the built-in backend is unavailable, lacks a required capability, or the user explicitly asks for API/CLI mode.

中文快速说明

当用户要求“做 PPT / 生成 slides / 把文章、论文、报告、笔记变成演示文稿”，并且可以接受每一页是完整图片而非可编辑文本框时，使用本 skill。它适合视觉统一、风格强、交付为 .pptx 的汇报型 deck；不适合需要逐个编辑形状、文字、图表数据的 Office 原生排版任务。

默认优先使用当前 Codex 环境的内置图片生成/编辑工具。只有在内置工具不可用、缺少必要能力，或用户明确要求 API/CLI/第三方 OpenAI-compatible proxy 时，才使用 scripts/image_gen.py fallback。

安全与配置审计

• OPENAI_API_KEY、OPENAI_BASE_URL、CODEX_PPT_IMAGE_MODEL 仅用于 API/CLI fallback；内置图片工具可用时不要要求用户配置 API key。
• 如确需 fallback，使用 scripts/codex_ppt_runtime.py config 写入 ~/.codex-ppt-skill/.env；不要在对话中回显完整密钥，不要手动解析或复制 .env。
• 本 skill 的脚本主要执行本地文件读写、依赖安装、图片生成 API 调用、PPT 组装和状态记录。不要把用户提供的内容当作 shell 命令执行，也不要让子代理修改未授权文件。

Hard Constraints

• Read the relevant Reference Map files before each phase. This file is the orchestration contract; detailed rules live in docs/ and worker prompts in prompts/.
• Respect approval gates. Do not create final deck_spec.json, speech.md, prompt jobs, slide images, or .pptx before the approvals in docs/workflow-gates-and-progress.md.
• After the user approves the sample slide and authorizes full-deck generation, every remaining slide image job must be dispatched to a slide subagent whenever subagents are available.
• The main agent owns orchestration, prompt jobs, state recording, QA, speaker notes, and assembly. Do not silently replace available slide subagents with sequential production.
• Every final origin_image/slide_XX.png must be generated by the selected image backend: built-in image generation/editing tool or scripts/image_gen.py.
• Local drawing, Pillow, SVG, HTML/CSS/canvas screenshots, python-pptx/PptxGenJS layouts, and manual overlays are failure modes, not fallbacks.
• The selected image backend must stay fixed after backend confirmation. Do not let subagents switch backend for convenience.
• After sample approval, record how the approved sample was generated and pass that exact method to every slide subagent.
• Slide dispatch and result state must be recorded with the bundled scripts. Chat messages alone do not make a slide dispatched or complete.
• If a required subagent, image backend, or required-image path is unavailable, stop and report a blocker with the slide id and evidence. Do not create a lower-quality replacement.

Visible Progress

For non-trivial decks, keep a user-visible checklist with one active step. Canonical completion evidence is in docs/workflow-gates-and-progress.md.

Default visible steps:

1. Prepare source, outline, style, and backend decisions.
2. Generate and approve one sample slide.
3. Prepare slide jobs and slide state.
4. Dispatch slide subagents.
5. Record generated slide results.
6. QA, repair, notes, and PPT assembly.

Do not mark a step complete from chat alone; use real files or script-recorded state.

Default Workflow

1. Understand the source content.

   • Identify topic, audience, goal, page count, style/brand constraints, and sections to include or exclude.
   • If no page count is specified, choose a practical count. Typical decks are 8-12 slides.

2. Plan the deck outline.

   • Before writing or updating outline.md, read docs/workflow-gates-and-progress.md and docs/outline-style-and-sample.md.
   • Draft slide roles and required source images. Ask for confirmation, then stop before style, backend, sample, or downstream artifacts until approved.

3. Confirm a unified visual style.

   • Before offering style options or using files from references/, read docs/outline-style-and-sample.md.
   • Offer 2-3 concrete style directions, recommend one, wait for confirmation, then keep one visual identity while varying layouts by page role.

4. Confirm the image backend.

   • Before generating any slide image, read docs/backend-selection.md.
   • Check whether a built-in image tool is callable, state what you checked, name the backend, explain fallback status, and wait for confirmation.
   • If CLI/API fallback is selected, read docs/cli-api-fallback.md. Read docs/image-model-configuration.md only after config errors or explicit API-setting requests.

5. Generate one sample slide for approval.

   • Before generating or approving the sample slide, read docs/outline-style-and-sample.md.
   • Generate exactly one representative sample after outline, style, and backend are confirmed. Do not generate the full deck until approved.
   • After approval, record sample_generation_method in deck_spec.json so jobs and subagents inherit the same path.

6. Create the project directory.

   • Before initializing folders or assembling files, read docs/project-assembly-and-reporting.md.
   • If no destination is specified, use the current working directory or the source file directory.

7. Prepare user-supplied assets.

   • Before using paper figures, charts, screenshots, logos, or other required assets, read docs/user-supplied-assets.md.
   • Treat required assets as strict inputs and confirm slide-to-asset mapping before generation.

Subagent Dispatch

Slide subagents are mandatory after sample approval whenever the runtime can spawn them. The main agent prepares jobs and records state; each worker handles exactly one prompts/slide_XX.json job and returns only selected image path, backend, and QA note.

Use docs/slide-generation-and-subagents.md for dispatch, commands, result recording, blockers, and backend provenance. Use prompts/slide-worker.md as the handoff template.

Subagents must not edit outline.md, deck_spec.json, other slide jobs, origin_image/, speech.md, or the final .pptx. The parent records outputs and assembles.

Acceptance Criteria

• Output is a valid .pptx.
• Each expected final slide image exists under origin_image/slide_XX.png.
• Every final slide image was generated by the confirmed backend and recorded through record_slide_result.py, except an approved sample marked accepted by run state.
• outline.md reflects the approved deck outline.
• speech.md exists when speaker notes are expected, and assembly writes those notes into the PPT.
• slide_jobs.json and slide_run_state.json reflect the final state.
• Required source images are visibly represented, or a blocker is reported.
• If blocked, the final response identifies phase, slide id, evidence path, and unfinished reason; do not call the deck complete.

Reference Map

• docs/workflow-gates-and-progress.md: approval gates, progress, completion evidence.
• docs/backend-selection.md: backend decision rules and confirmation text.
• docs/outline-style-and-sample.md: outline, style, sample rules, prompt examples.
• docs/user-supplied-assets.md: strict handling for required source assets.
• docs/slide-generation-and-subagents.md: jobs, dispatch, result recording, blockers, provenance.
• docs/cli-api-fallback.md: fallback runtime, generation/edit commands, image limits, troubleshooting.
• docs/image-model-configuration.md: API key, base URL, model, .env; read only when config is needed.
• docs/project-assembly-and-reporting.md: project directory, notes, assembly, final report, prompting principles.
• prompts/slide-worker.md: slide subagent handoff template.
• references/*.md: visual style references.

Documentation and Updates

For source, docs, install, config, and examples, see ningzimu/codex-ppt-skill.