feat: add Phase 6C — export to editable PPTX via dom-to-pptx

[Enderfga]

Summary

Adds an editable PPTX export alongside the existing PDF export. Every text run becomes a native PowerPoint text frame; CSS gradients become vector SVGs; box-shadows map to real PowerPoint shadows; <img> elements embed as picture shapes. The deck remains directly editable in PowerPoint, Keynote, Google Slides, and WPS.

This addresses #28 — both the original PDF request (already merged) and @Hannsek's follow-up "Also maybe to pptx/google slides with all the animations". PPTX is the right answer for a class of cases PDF doesn't cover: venue laptops that only accept .pptx, collaborators who want to edit text right before presenting, repurposing individual slides in other decks.

What's added

• scripts/export-pptx.sh — self-contained CLI that mirrors export-pdf.sh's UX (auto-installs Playwright + dom-to-pptx into a temp dir on first run, serves the deck over local HTTP, opens result on success).
• SKILL.md § 6C — Phase 6C documents usage, what the export produces, and the gotchas (layout fidelity for deeply-nested flex, fonts / CORS, animation handling, file size).
• README.md — new "Export to editable PPTX" subsection, supporting-files row, and a requirements bullet.
• Plugin symlink — plugins/frontend-slides/skills/frontend-slides/scripts/export-pptx.sh symlinks to the real script, matching the layout already used for deploy.sh, export-pdf.sh, extract-pptx.py.

Usage

bash scripts/export-pptx.sh ./my-deck/index.html
bash scripts/export-pptx.sh ./presentation.html ./output.pptx

How it works

1. Starts a tiny local HTTP server so fonts + relative assets resolve cleanly.
2. Launches headless Chromium at 1920×1080 (which maps 1:1 onto PowerPoint's standard 13.33"×7.5" widescreen canvas).
3. Injects the dom-to-pptx bundle into the page.
4. Force-reveals every .reveal / .visible element so off-screen content is fully laid out before measurement.
5. Hands Array.from(document.querySelectorAll('.slide')) to domToPptx.exportToPptx(), gets a Blob back, base64-encodes it on the page, decodes it back in Node, writes the .pptx.

dom-to-pptx is MIT-licensed and stable (~180 ⭐, active maintenance, v1.1.9 ships an official browser bundle).

Tested on

• An entire 27-slide deck I built earlier this evening using this skill — produces 27 slides with 7–25 native shapes each (text + images + gradients + shadows), all directly editable in PowerPoint. Same input fed to a screenshot-based exporter would give 27 non-editable picture shapes.
• Includes the --compact flag-style escape hatch nowhere (kept the CLI surface minimal — happy to add flags if useful).

Tradeoffs / known limits

• dom-to-pptx maps computed styles, not pixels. This is its main advantage (editable output) but also the biggest behaviour difference vs PDF export: decks that present cleanly to humans but rely on deeply nested flexbox with 100vh height inheritance can produce slides where some shapes are missed. The new SKILL.md guidance recommends fixed 1920×1080 absolute positioning for max fidelity, which dovetails with what viewport-base.css already targets.
• Animations are static. Same as PDF export.
• First run downloads ~150MB (Playwright + Chromium). Same as PDF export — the same Chromium cache is reused if you've already exported a PDF.
• Output is one-way. Editing HTML later requires re-export.

What I'm not doing

• Not bundling dom-to-pptx as a hard dependency in the repo — it installs into the temp dir at runtime, same pattern as Playwright.
• Not changing the existing PDF export or its UX in any way.
• Not editing the deploy script or other unrelated paths.

Happy to iterate on the wording, flag surface, gotcha list, or the SKILL.md placement.