メニュー
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.
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 | brief-to-presentation-plan |
| description | 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. |
Use this skill when the user provides source material and wants a presentation created from it. The job here is to turn raw input into a clear plan, not to design slide layouts yet.
Canonical slide rules: load ../_shared/slide-philosophy.md before planning. Every slide intent must satisfy all four pillars: one thought, minimum text (≤1 sentence besides graphics/labels/titles), visual-first, and forward motion (reveals + 10–35 s pace + named transition).
This skill supports more than one presentation shape. One important supported scenario is a story-driven engineering deck that:
When this scenario applies, the plan must lock the story facts, visual direction, motion strategy, and delivery constraints early. Do not leave those decisions to improvisation during deck build.
Worked example:
docs/examples/proper-presentation-deck.md — presentation made with presentation-skillsSupported starting points:
If the input is fragmented, normalize it first into a single working summary.
Read the source carefully Extract the main topic, business context, explicit asks, and implied stakes.
Identify the presentation outcome Determine what the audience should understand, decide, believe, or do after the presentation. Also identify the delivery mode:
Define the audience Infer or ask about:
Find the through-line Reduce the presentation to one sentence. Every section should support that sentence.
Apply critical thinking Pressure-test the material:
Choose the story shape
Two canonical arcs. Pick one and use it consistently in the plan; do not blend them.
Generic arc (default):
Engineering-story arc — use for an incident, migration, launch, regression, diagnosis, or fix retold as one narrative:
The output template below has a slot for whichever arc you pick.
Create the presentation plan Produce:
Save the plan to the project
Write the plan to <project-root>/docs/specs/YYYY-MM-DD-<slug>-design.md (see File location below). Create docs/specs/ if it does not exist. Tell the user the exact path after saving.
Every plan must be saved to the target project's specs folder using a dated, descriptive filename:
<project-root>/docs/specs/YYYY-MM-DD-<kebab-slug>-design.md
Example:
<project-root>/docs/specs/2026-04-17-presentation-skills-lightning-talk-design.md
Rules:
YYYY-MM-DD is today's date in ISO format.<kebab-slug> is a short lowercase, hyphen-separated slug tied to the talk topic.-design.md.docs/specs/ if it does not exist — do not fall back to another path.plans/, in docs/ directly, or next to deck files.Use this structure unless the user asks for another format:
# Presentation plan
## Goal
[What this presentation must achieve]
## Audience
[Who is in the room, what they know, what they need]
## Through-line
[One-sentence core message]
## Stakes
[Why this matters now]
## Key tensions
- [Tension 1]
- [Tension 2]
## Narrative arc
[Pick one — Generic OR Engineering-story — and fill in the matching beats. Delete the other.]
**Generic arc:**
1. Setup
2. Orientation
3. Development
4. Complication
5. Resolution
6. Landing
**Engineering-story arc:**
1. Hook
2. Stakes
3. Investigation
4. Aha / diagnosis
5. Fix
6. Result
7. Lesson
8. Recap / navigation / CTA
## Deck structure
1. [Section name]: [purpose]
2. [Section name]: [purpose]
## Slide intents
1. [Slide title] — [one main thought (one plain sentence, no "and"); primary visual proof; reveal intent; forward transition to next slide]
2. [Slide title] — [one main thought; primary visual proof; reveal intent; forward transition]
## Format and delivery
- Format: [HTML deck / PPTX / other]
- Aspect ratio: [explicitly chosen; 16:9 is the usual default, 9:16 is valid for intentional vertical delivery]
- Delivery mode: [live talk / async / review]
- Runtime: [browser / PowerPoint / other]
- Support matrix: [for HTML decks, latest Chrome and Firefox are required; add Safari when relevant]
## Visual system
- Style direction: [clean / technical / bold / formal / etc.]
- Palette / contrast rules: [what visual language the deck uses]
- Typography / density rules: [minimum text; visuals carry the explanation; how the deck should read in a live room]
- Intentional contrast: [for example, plain "before" act vs polished "after" act]
## Motion / reveal strategy
- Reveal model: [none / fragments / animated charts / staged proof / auto-animate]
- Evidence-to-conclusion overlays: [slides where 3-4 statement cards should reveal a centered synthesis overlay instead of a bottom takeaway]
- Resulting thought / final payoff layers: [slides where the lesson, standard, decision, pattern, principle, or "so what" must land as its own slide or as a dominant final hero / overlay]
- Navigation cues: [progress bar / act labels / recap map / none]
- Replay requirement: [what must re-run when revisiting a slide]
## Canonical facts
- [Shared numbers, dates, thresholds, names, and cause/effect facts that must stay consistent across slides]
## QA / verification
- [Stagecraft checks, browser checks, runtime checks, timing checks, export checks]
## Gaps / questions
- [Missing evidence, unclear claim, unresolved choice]
Slide rules: every planned slide must satisfy the four pillars in ../_shared/slide-philosophy.md. The plan is rejected if any slide intent violates one of them at the planning stage.
Plan-level requirements on top of the pillars:
../_shared/evidence-to-conclusion-overlay.md).Once the plan file is saved under docs/specs/ and approved, hand off to presentation-plan-to-deck using that saved file as the source of truth for the deck build.