Plan, generate, review, and iteratively maintain presentation decks through a guide-first workflow. Use when Codex needs to create or revise slide decks, `.pptx` presentations, pitch decks, training decks, board updates, paper readings, product reviews, or other decks that should remain editable across multiple rounds. Trigger when the task benefits from keeping a source-of-truth `PPT_GUIDE.md`, a committed generator such as `generate_ppt.js` or `generate_ppt.py`, and a render/review loop so human feedback can be routed into guide updates, generator fixes, or both.
HansBug0 星标2026年4月10日
职业
分类
技术文档
技能内容
Overview
Treat deck work as a managed production loop, not a one-shot export.
Keep a stable source of truth for narrative and structure, a committed generator for implementation, the generated deck file, and rendered review artifacts for QA and incremental fixes.
Non-Negotiable Contract
Follow these rules whenever the deck is meant to survive more than one quick pass:
Create the workspace inside the user's repo or another durable project directory, not in a transient scratch directory.
Keep PPT_GUIDE.md as the upstream source of truth for deck intent.
Keep generate_ppt.js or generate_ppt.py as the implementation layer.
Keep the .pptx as a generated artifact, not the only source of truth.
Keep rendered outputs or review notes whenever visual QA matters.
Route each change into the correct source artifact before regenerating.
Keep stable slide ids for review and change routing, but do not surface ids such as s01-cover on visible slides unless the user explicitly wants them.
相关技能
Treat speaker notes as a deliverable when the deck is meant to be presented, not as optional guide-only prose.
Put important formulas on-screen when they carry the core argument, and explain their symbols and meaning for the audience.
Do not declare success without reviewing rendered output.
If a user asks for an existing deck to be changed and no guide exists, reconstruct a minimal guide first before making substantial changes.
Standard Production Loop
Follow this loop in order for new decks and most non-trivial revisions:
Inspect the request, constraints, source materials, and any existing deck workspace.
Create or repair PPT_GUIDE.md before implementing the deck.
Implement or update generate_ppt.js or generate_ppt.py to match the guide.
Generate the editable deck file.
Render the deck to PDF or per-slide images.
Review the rendered output and log issues in review/notes.md.
Decide whether each issue belongs to the guide, the generator, or both.
Fix the right source artifact.
Rebuild and re-review until the major issues are closed.
Treat the sequence PPT_GUIDE.md -> generate_ppt.* -> deck file -> rendered review -> source updates -> rerender as the default contract, not as optional advice.
Write or reconstruct the guide before building unless the task is a tiny disposable mockup.
Keep these guide rules:
Define one deck-level goal so the whole deck has a single main thread.
Give every slide a stable slide id once review begins.
Treat slide ids as internal production metadata; keep them in the guide, generator, comments, and review notes rather than visible slide text unless explicitly requested.
Give every slide one main message, not a bucket of unrelated content.
Keep visible text audience-facing; keep presenter instructions in speaker notes or the guide.
State what visuals are required and where they come from.
State acceptance checks per slide so later review is concrete.
When the deck is spoken, make speaker notes direct enough that a presenter can read them aloud with minimal improvisation.
When the final deck needs embedded notes, state whether notes equal the read-aloud script only or script plus explicit supplements.
When a slide needs an important formula, state the expression, compact-vs-full choice, visible symbol explanations, speaking order, and layout requirements.
When the deck will be generated automatically, make slide instructions concrete enough that the generator can implement them without guessing.
Implement the generator only after the guide is coherent enough to build against.
Keep these generator rules:
Match the guide's slide order and slide ids.
Keep internal slide ids in code structure, review notes, or comments instead of audience-facing text unless explicitly requested.
Keep theme, helper logic, asset prep, and slide builders in source control.
Prefer editable text, shapes, and charts whenever practical.
Render code snippets, inline code labels, terminal commands, and other code-like visible text in a monospaced font unless the user explicitly wants another treatment.
Avoid direct manual-only edits to the exported .pptx unless the change is truly urgent and then backport it into source immediately.
Keep visible text, speaker notes, and deck metadata in sync with the guide.
If notes must be embedded, verify the final .pptx actually contains notes for the expected slides.
If formulas are important, use a reliable native-equation or deterministic asset path and treat formula pages as high-risk render-review pages.
Use stable output paths so review commands and CI-like checks stay repeatable.
If the official $slides skill is available and the project is not already committed to another stack, prefer its PptxGenJS helpers and validation utilities for low-level authoring.
Backend Choice
Choose the backend deliberately instead of mixing stacks casually.
Prefer JavaScript when:
The project is new and no backend is established.
The official $slides skill is available.
Editable PowerPoint-native authoring and helper utilities matter most.
The deck is heavy on layout composition, charts, or repeatable component logic.
Prefer Python when:
The existing project is already Python-based.
The deck pipeline depends on python-pptx, PyMuPDF, Pillow, or pdf2image.
The work includes PDF cropping, image extraction, or document-side preprocessing that already lives in Python.
The team is more likely to maintain the generator in Python.
The repo can reasonably support a local virtual environment even if the current shell is missing deck libraries.
Do not switch a working project from Python to JavaScript or the reverse without a clear reason.
Do not fall back from Python to JavaScript only because python-pptx or related packages are missing globally; first try a workspace-local venv and install the required Python dependencies.