slide-wright

Turn a topic or rough notes into a boardroom-grade presentation: slides that read like a deck from a strong strategy or product team, delivered as a single self-contained HTML file that runs in any browser.

The rule that defines this skill

Propose the look before you build the deck. On the first pass you never produce a finished presentation. You ask how many design directions the user wants to compare and whether they want animation, build a two-slide preview of each direction, and stop until the user picks one. Only then do you build the rest.

If the user says no, throw the directions out and try clearly different ones. Every theme is invented for the deck in front of you; there is no library of presets.

New deck: read slide-wright/references/new-deck.md first. It holds Steps 1-4 (work out the deck and ask the two questions, propose the look, get a yes, build) and the exact approval gate.

The engine (keep this internal)

Decks render with reveal.js loaded from a CDN, but that is an implementation detail the user never sees. Talk about slides, themes, and design; the library name appears only inside the generated <link> and <script> tags. slide-wright/references/deck-template.md has the exact setup.

Editing a deck that already exists

If the user points at an existing HTML deck, check whether it's built on reveal.js (look for the reveal.js <link>/<script> tags from a CDN). If it is — whether or not this skill built it — don't start over: read it, keep its theme, and make the change in place. The look is already approved, so skip the proposal and the gate. After editing, run node <skill-dir>/scripts/check-deck.mjs <deck.html> and fix every line it prints (slide-wright/references/new-deck.md has the details).

No reference files are needed for an edit, unless you add a new exhibit type (read slide-wright/references/exhibits.md) or code or animation (read slide-wright/references/code-slides.md or slide-wright/references/motion-recipes.md).

If the deck is HTML but not on reveal.js (different engine, plain slides, etc.), it's outside this skill's edit path — say so rather than forcing a rewrite onto a different engine. Everything else here is for building a new deck.

Step 5 — Hand it off

1. Open the finished deck.
2. Say where it lives, the theme name, and the slide count.
3. Tell the user how to drive it: arrow keys, space, or swipe to move; F for fullscreen, Esc or O for the slide overview, S for the speaker view with notes; add ?print-pdf to the URL and print to save a PDF (slide-wright/references/export-pdf.md has the steps); theme colors live in the :root variables, fonts in the <link>.
4. Offer the obvious next moves: revise the content, change the theme, export a PDF, export a PowerPoint file (slide-wright/references/export-pptx.md), or deploy to a live URL to share it. If they want to deploy, read slide-wright/references/deploy.md and let them pick the host (Surge, Vercel, or Netlify) — don't assume one.

Reference files

Read each when you reach it, once; never all at once:

• slide-wright/references/new-deck.md — Steps 1-4 for a new deck
• slide-wright/references/design.md — inventing a theme and what makes a deck look designed (Step 2)
• slide-wright/references/deck-template.md — the HTML skeleton, layout, and engine setup (Step 2)
• slide-wright/references/exhibits.md — choosing and building the visual on each content slide (Step 2)
• slide-wright/references/motion-recipes.md — animation, when the user chose it (Step 2)
• slide-wright/references/code-slides.md — code slides and their markup contract (Step 4)
• slide-wright/references/media.md — images and video in slides (Step 4)
• slide-wright/references/export-pdf.md — saving a deck as a PDF (Step 5)
• slide-wright/references/export-pptx.md — exporting a deck to PowerPoint with editable text (Step 5)
• slide-wright/references/deploy.md — publishing the deck to a live URL (Step 5)