菜单
Converts an approved presentation plan into a concrete presentation deck. Use when you already know the audience, through-line, and slide flow and now need to produce slide structure, layout decisions, reveal order, animation, and implementation-ready deck content.
Converts a brief, notes, transcript, document, or mixed source material into a presentation plan and saves it to the project's `docs/specs/` folder. Use when the input is messy or incomplete and you need to extract audience, goal, theme, narrative arc, section flow, and slide intent before building a deck.
Reviews a presentation deck for story consistency, pacing, structure, and audience fit, then proposes or applies concrete improvements. Use when a deck draft exists and you need to identify what is weak, confusing, redundant, or missing and update it accordingly.
Guided discovery for new presentations when there is no brief, notes, or source material yet. Asks structured questions one at a time to establish audience, format, tone, takeaway, and narrative direction, then produces a brief that feeds into brief-to-presentation-plan.
Adds themed GIFs to selected slides in an existing deck. Use when a deck draft exists and the user wants to inject humor or energy with GIFs — picks a deck-wide theme (e.g. Matrix, Pixar, Office), lets the user choose which slides get a GIF, searches Giphy, and offers 3 options per slide.
Turns numeric results, improvements, and comparisons into bold visual treatments instead of inline prose. Use on any slide that contains a number representing a result, change, gain, loss, target, or benchmark — bars, gauges, hero numbers, before/after panels, delta callouts, with a reason label explaining why the number moved.
| name | presentation-plan-to-deck |
| description | Converts an approved presentation plan into a concrete presentation deck. Use when you already know the audience, through-line, and slide flow and now need to produce slide structure, layout decisions, reveal order, animation, and implementation-ready deck content. |
Use this skill after the presentation plan is settled. The job here is to turn the plan into a deck with accurate structure, layout, and reveal logic.
Canonical slide rules: load ../_shared/slide-philosophy.md before building. Every slide must satisfy all four pillars: one thought (one plain sentence, no "and"), minimum text (≤1 sentence besides graphics/labels/titles), visual-first, forward motion (default to step reveals; 10–35 s pace; named transition; reveal sync; replay on revisit). A resulting thought, lesson, standard, decision, pattern, principle, or "so what" must either be its own slide or land as a dominant final payoff layer.
For new decks, default to the simple stack described in references/simple-reveal-deck.md — Reveal.js 5.x from CDN, single index.html, no build tool, no installed dependencies.
If the project already has a bespoke single-file HTML deck with custom reveal systems, also read references/html-slide-deck.md and the project maintainer documentation. Do not retrofit legacy patterns onto a new deck.
Also read references/ux-design-regressions.md before building or revising any deck with custom visuals, charts, or reveal-heavy storytelling. It names the failure modes that make a deck feel broken even when the HTML technically renders.
This skill must support decks that tell one engineering story as a sequence of scenes: an incident, launch, migration, performance regression, diagnosis, or fix retold with escalating proof.
Common shape:
For this scenario:
Worked example:
docs/examples/proper-presentation-deck.md — presentation made with presentation-skillsExpected input:
If the plan is weak or incomplete, stop and send it back to brief-to-presentation-plan rather than improvising a deck on shaky foundations.
Lock the deck contract Before building slides, define:
index.html, .pptx, or other)index.html, serve locally, or export a .pptx)Default for live HTML decks:
Translate plan to slide units Default rule: one slide, one main thought. The thought should fit in one plain sentence and point to a simple implication, answer, decision, or solution. If a slide needs two thoughts, split it.
Assign each slide a job For every slide, define:
Choose composition Decide whether the slide is best expressed as:
stats-visualizationWrite a composition contract Before implementing the slide, define:
Specify reveal order Reveals and animation should match the spoken story:
Design for presentation readability
Large readable text, strong contrast, clean visual hierarchy, room-scale composition. The four pillars in ../_shared/slide-philosophy.md are the bar — especially the one-sentence text ceiling and the default-to-reveals rule. No website-density slides, no bullet-heavy slides.
Produce implementation-ready deck content The output can be:
Run human stagecraft QA before completion This is a blocking pass, not optional polish.
Use this format when building or handing off the deck:
## Slide N — [Title]
- Purpose: [what this slide must achieve]
- Audience takeaway: [what they should leave with]
- Main thought: [one plain sentence; split the slide if this needs an "and"]
- Body text budget: [≤1 sentence besides graphics, labels, and titles]
- Simple implication / solution: [what the thought makes obvious]
- Scenario role: [hook / stakes / investigation / fix / result / lesson / recap / other]
- Content:
- [short label or claim]
- Primary visual: [graph / picture / diagram / screenshot / demo / spatial comparison]
- Format / runtime: [16:9 or 9:16 HTML Reveal deck / PPTX / other]
- Visual system: [palette, type, contrast model, intentional theme contrast if any]
- Layout: [diagram / 2-column / sequence / card grid / hero / proof scene]
- Resulting thought / payoff treatment: [none / own slide / hero statement / conclusion overlay; never a footer if it is the point]
- Evidence sync: [what visual proof appears with each reveal / step]
- Opening state: [what is visible before any reveal]
- Reveal / animation order:
1. [first element]
2. [second element]
- Build notes: [built-in fragments only / custom SVG / custom JS / replay requirement]
- QA checks: [specific readability, replay, browser, or spacing checks]
- Transition forward: [what the slide hints at or sets up; why the next slide naturally follows]
- Estimated time on screen: [target 10–35 s; if longer, split]
When a slide has 3–4 statement / principle / summary cards building to one synthesis, use the canonical treatment in ../_shared/evidence-to-conclusion-overlay.md. Replace any bottom-of-slide takeaway with the overlay reveal (cards → scrim + centered conclusion panel).
When the user asks "what is this presentation about?" or "write a description of this presentation", generate a short friendly text — not a slide, not a list.
The output format:
Summary: [title of the presentation — one short phrase] Description: [2–4 sentences in plain, warm language covering what the audience will get out of it]
Write it as if it were the body of a calendar invite or an email to attendees. The tone should feel like an invitation: give enough context to make someone want to show up, without summarising every point. No bullet lists, no jargon, no agenda structure.
Example output:
Summary: Onboarding flow review
Description: We'll walk through how the current onboarding experience works, what we've changed recently based on user feedback, and where we're taking it next. Whether you're new to the product or just want a refresher, this session will give you the full picture.
Slide pillars are blocking. Any pillar violation in ../_shared/slide-philosophy.md — one thought, ≤1 body sentence besides graphics/labels/titles, visual-first, forward motion — fails the deck.
Deck-build-specific rules on top of the pillars:
stats-visualization — hero number, before/after, bars, gauge, delta callout, or annotated change chart — with a reason label explaining why the number moved. Inline phrasing like "340 ms vs 65 ms" is a bug.index.html, no build, no installed dependencies (see references/simple-reveal-deck.md). Do not add a bundler, package manager, CSS framework, or bespoke navigation system unless a concrete requirement demands it and the default has been tried first.Before a deck is considered complete, run the canonical human stagecraft QA pass in ../_shared/stagecraft-qa.md. It is a blocking gate, not optional polish.
Judge every slide as a stage object for a live room, not as a browser screenshot. Revise and re-check until every checklist answer is no.
For new decks, follow the simple default stack:
index.html, no build, no install:root; no stray hex colorsFor existing decks with a bespoke single-file HTML framework:
For any HTML deck, verify at least:
Check:
If Firefox breaks the slide, the deck is not done.
If the deck depends on custom motion, staged proof, annotation placement, or revisit replay, add a lightweight repeatable QA check for the critical slides instead of relying on memory.
Typical checks:
This does not replace human stagecraft review. It prevents silent regressions in the parts of the deck where timing and layout are carrying meaning.
After a draft exists, use deck-review-update for the final review pass. When the deck technically works but still feels wrong, use references/deck-hardening-prompt.md to frame the regression pass. A deck is not complete until it passes story review and human stagecraft QA with every checklist answer set to no.