PPT Studio

Produce editable PowerPoint files through an evidence-driven loop: inspect inputs, plan the narrative, build or revise the deck, validate the package, render every slide, correct visible defects, and deliver only the finished file.

Treat the platform as providing raw files and ordinary sandbox tools. Do not assume a platform PPT parser exists.

Bootstrap once per sandbox

Resolve this skill directory from the loaded skill path and keep it in PPT_STUDIO_DIR. Check dependencies before installing them:

python3 -c "import pptx, PIL, defusedxml"
node -e "import('pptxgenjs')"

If Python imports fail, install requirements.txt. If the Node import fails, run npm install --prefix "$PPT_STUDIO_DIR" and execute Node scripts from this directory so module resolution is stable. Never bundle node_modules, a virtualenv, LibreOffice, or Poppler into the delivered Skill.

Choose the path

• Read or summarize: run scripts/extract_pptx.py and inspect both Markdown and JSON.
• Create from scratch: write a compact deck specification and run scripts/build_deck.mjs.
• Revise a simple existing deck: use python-pptx while preserving individual runs and object geometry.
• Revise a complex template: unpack with scripts/ooxml_package.py, make narrow OOXML changes, repack, then validate against the original.
• Understand layout or verify output: render slides with scripts/render_slides.py; do not infer visual quality from extracted text.

Read references/editing.md before changing an existing deck. Read references/design-system.md before creating a new visual system. Read references/monkeys-runtime.md when Monkeys tools are available.

Required workflow

1. Inspect every referenced source file. For PPTX input, extract content.md, structure.json, and embedded media.
2. Decide the audience, decision or learning goal, length, tone, and evidence requirements. Ask only for information that changes the result materially.
3. Write the complete slide outline before authoring slides. When slide_outlined exists, emit it once per planned slide in order.
4. Select a coherent visual system and assign a distinct communication job to every slide.
5. Generate original imagery with image_generate when it materially improves the deck. Prefer one strong scene or diagram over decorative filler. Use returned localPath files as ingredients; do not re-deliver those source images.
6. Build or revise one slide at a time. When available, call slide_started before work on a slide and slide_finished after its content is written.
7. Run structural validation. Any error blocks delivery.
8. Render all slides to images. Inspect text fit, clipping, overlap, alignment, contrast, image crop, chart legibility, and unintended leftovers.
9. Fix defects in the source/specification, regenerate, and rerun validation and rendering. Never patch a final binary blindly.
10. Run content extraction on the final PPTX and verify slide order, titles, notes, numbers, names, and sources.
11. Put only final deliverables in output/. Call deliver_file exactly once per requested final file.

Creating a deck

Use scripts/build_deck.mjs for the supported layouts:

node "$PPT_STUDIO_DIR/scripts/build_deck.mjs" deck-spec.json --out output/deck.pptx

The input format is documented in references/deck-spec.md. Keep the specification as the source of truth so corrections are reproducible.

Use native PowerPoint text, shapes, tables, and charts whenever they must remain editable. Use generated or photographic images for scenes, atmosphere, products, people, and illustrations. Do not turn an entire slide into a flat image unless the user explicitly requests a non-editable deck.

Reading a deck

python3 "$PPT_STUDIO_DIR/scripts/extract_pptx.py" input.pptx \
  --markdown work/content.md \
  --json work/structure.json \
  --media-dir work/media

The extractor records slide text, notes, tables, charts, object bounds, and embedded images. It does not reproduce rendering. Use the renderer for visual claims.

Editing a deck

Prefer the least invasive method:

1. Change text inside existing runs when formatting must remain intact.
2. Use python-pptx for ordinary object edits supported by its public API.
3. Use OOXML only for unsupported features or template-preserving structural work.

For OOXML work:

python3 "$PPT_STUDIO_DIR/scripts/ooxml_package.py" unpack input.pptx work/unpacked
python3 "$PPT_STUDIO_DIR/scripts/ooxml_package.py" pack work/unpacked output/revised.pptx

Do not duplicate slide XML by hand. A slide can own relationships to notes, charts, media, layouts, comments, and embedded objects. If a requested structural edit is not implemented safely, rebuild the affected slide or deck instead of producing a corrupt package.

Validation and visual QA

Run both checks:

python3 "$PPT_STUDIO_DIR/scripts/validate_pptx.py" output/deck.pptx
python3 "$PPT_STUDIO_DIR/scripts/render_slides.py" output/deck.pptx --out-dir work/rendered

If LibreOffice or Poppler is unavailable, report that visual QA is blocked. Structural validation alone is not evidence that slides look correct.

Reject delivery when any of these remain:

• missing or clipped text;
• overlapping content;
• unreadable contrast or type size;
• inconsistent spacing or alignment;
• stretched or poorly cropped imagery;
• placeholder text or template artifacts;
• unsupported claims presented without a source;
• package validation errors.

Safety and integrity

• Work only inside the sandbox workspace.
• Treat PPTX/POTX as untrusted ZIP/XML input; use the bundled safe extractor.
• Never execute macros or embedded programs.
• Do not invent citations, data, or visual-inspection results.
• Do not claim compatibility from file creation alone; report the checks actually run.
• Preserve originals and write edits to a new file unless the user explicitly requests replacement.