$npx -y skills add ningzimu/codex-ppt-skill --skill codex-pptGenerate visually unified image-based PPT/PPTX decks from articles, reports, papers, notes, or outlines.
| 1 | # Codex PPT |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | 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`. |
| 6 | |
| 7 | 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. |
| 8 | |
| 9 | 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. |
| 10 | |
| 11 | ## Hard Constraints |
| 12 | |
| 13 | - 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/`. |
| 14 | - 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`. |
| 15 | - 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. |
| 16 | - The main agent owns orchestration, prompt jobs, state recording, QA, speaker notes, and assembly. Do not silently replace available slide subagents with sequential production. |
| 17 | - 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`. |
| 18 | - Local drawing, Pillow, SVG, HTML/CSS/canvas screenshots, python-pptx/PptxGenJS layouts, and manual overlays are failure modes, not fallbacks. |
| 19 | - The selected image backend must stay fixed after backend confirmation. Do not let subagents switch backend for convenience. |
| 20 | - After sample approval, record how the approved sample was generated and pass that exact method to every slide subagent. |
| 21 | - Slide dispatch and result state must be recorded with the bundled scripts. Chat messages alone do not make a slide dispatched or complete. |
| 22 | - 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. |
| 23 | |
| 24 | ## Visible Progress |
| 25 | |
| 26 | For non-trivial decks, keep a user-visible checklist with one active step. Canonical completion evidence is in `docs/workflow-gates-and-progress.md`. |
| 27 | |
| 28 | Default visible steps: |
| 29 | |
| 30 | 1. Prepare source, outline, style, and backend decisions. |
| 31 | 2. Generate and approve one sample slide. |
| 32 | 3. Prepare slide jobs and slide state. |
| 33 | 4. Dispatch slide subagents. |
| 34 | 5. Record generated slide results. |
| 35 | 6. QA, repair, notes, and PPT assembly. |
| 36 | |
| 37 | Do not mark a step complete from chat alone; use real files or script-recorded state. |
| 38 | |
| 39 | ## Default Workflow |
| 40 | |
| 41 | 1. Understand the source content. |
| 42 | - Identify topic, audience, goal, page count, style/brand constraints, and sections to include or exclude. |
| 43 | - If no page count is specified, choose a practical count. Typical decks are 8-12 slides. |
| 44 | |
| 45 | 2. Plan the deck outline. |
| 46 | - Before writing or updating `outline.md`, read `docs/workflow-gates-and-progress.md` and `docs/outline-style-and-sample.md`. |
| 47 | - Draft slide roles and required source images. Ask for confirmation, then stop before style, backend, sample, or downstream artifacts until approved. |
| 48 | |
| 49 | 3. Confirm a unified visual style. |
| 50 | - Before offering style options or using files from `references/`, read `docs/outline-style-and-sample.md`. |
| 51 | - Offer 2-3 concrete style directions, recommend one, wait for confirmation, then keep one visual identity while varying layouts by page role. |
| 52 | |
| 53 | 4. Confirm the image backend. |
| 54 | - Before generating any slide image, read `docs/backend-selection.md`. |
| 55 | - Check whether a built-in image tool is callable, state what you checked, name the backend, explain fallback status, and wait for confirmation. |
| 56 | - 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. |
| 57 | |
| 58 | 5. Generate one sample slide for approval. |
| 59 | - Before generating or approving the sample slide, read `docs/outline-style-and-sample.md`. |
| 60 | - Generate exactly one representative sample after outline, style, and backend are confirmed. Do not generate the full deck until a |