メニュー
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.
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.
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.
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.
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 | deck-review-update |
| description | 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. |
Use this skill when the deck already exists and needs critical review plus concrete improvement.
The main job is not cosmetic polish. It is to judge whether the deck tells the right story, in the right order, for the right audience, and then tighten it.
Canonical slide rules: load ../_shared/slide-philosophy.md. Any pillar violation is a blocking finding: 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).
This skill explicitly covers story-driven engineering decks that retell one incident, launch, migration, regression, or fix across multiple slides, often using:
When reviewing this kind of deck, treat story continuity, proof timing, runtime behavior, and build constraints as first-class concerns, not implementation details.
Worked example:
docs/examples/proper-presentation-deck.md — presentation made with presentation-skillsCheck for:
stats-visualization)Reconstruct the intended story Infer the likely goal, audience, and through-line from the deck. Also reconstruct the build/runtime contract:
Test coherence Ask:
Find the highest-leverage issues Prioritize structural problems before wording tweaks.
Recommend updates Prefer specific changes:
Apply updates when requested Update the deck or its slide spec so the story becomes cleaner and more persuasive.
Run human stagecraft QA before declaring the deck done This is a blocking completion gate.
noWhen reviewing, use this structure:
## Findings
1. [Most important issue]
- Why it matters
- What to change
2. [Next issue]
- Why it matters
- What to change
[Use the canonical reporting format from [`../_shared/stagecraft-qa.md`](../_shared/stagecraft-qa.md) — both Human stagecraft QA and Build / Runtime QA sections.]
## Suggested update plan
1. [Change]
2. [Change]
3. [Change]
If there are no major issues, say that explicitly and call out any residual risks or testing gaps.
yes answer in the canonical checklist is not done.../_shared/evidence-to-conclusion-overlay.md).During review, scan every slide for numbers that represent a result, improvement, change, target, or benchmark (latency, adoption, cost, error rate, revenue delta, etc.). Flag any slide where those numbers appear as inline prose, bullet text, or a raw table.
Default action: redesign the slide per stats-visualization — hero number, before/after, bars, gauge, delta callout, or annotated change chart. Every such slide must also carry a short reason label explaining why the number moved (e.g., "added cache", "new algorithm", "A/B test winner"). A delta without a reason is trivia.
Do not treat this as a polish issue — it is structural. A deck that buries its best numbers is a deck that loses its audience.
During review, flag any slide that is doing too much. Signs of a complicated slide:
Default action: split into separate slides.
Each split slide gets one sentence-level thought, one proof object, its own title/subtitle, and a reveal path that can land in 10-35 seconds. A bad/good pair counts as one proof object; two bad/good pairs are two slides unless the slide is explicitly a recap/index with label-only cards. Prefer two clean slides over one complex one. A slide that needs a tour guide is a slide that needs to be broken apart.
During review, inspect the slide at thumbnail/contact-sheet size and ask: "Would the speaker need to tour the audience through separate quadrants?" If yes, split before polishing copy.
Run the canonical pass in ../_shared/stagecraft-qa.md. It is a blocking completion gate.
If the deck problems come from a weak plan rather than weak execution, send it back to brief-to-presentation-plan or presentation-plan-to-deck as appropriate instead of patching endlessly.