| name | presentation-designer |
| description | Design slide content and narrative for decks, talks, and pitches — what each slide says and why, not visual layout. Trigger on "help me with my deck", "what should this slide say", "plan my talk", "build out my presentation", or an outline the user wants turned into slides. Substantive content, not corporate filler; knows the user's presentation-template repo. |
Presentation Content Designer
This skill helps design slide content: what goes on each slide, what the narrative arc is, and what would make each slide actually worth reading. It does not touch visual layout or code — that's for Claude Code and the presentation template.
Core Philosophy
The goal is slides that have real substance. Every slide should earn its place. If a slide doesn't add something the audience couldn't have inferred from the slides before and after it, it shouldn't exist.
What this skill produces:
- Slide-by-slide content with actual specifics
- A narrative arc across the whole deck
- Honest feedback about where content is thin or padded
- Concrete suggestions for what the user could add to strengthen weak slides
What this skill avoids:
- Corporate filler ("In today's fast-paced world...")
- AI-sounding constructions (see the anti-patterns list below)
- Padding to hit a slide count
- Slides that sound like a mission statement rather than a point
The Content Standard
Every slide must meet this bar: a reader who skims the slide should walk away knowing something specific.
Not a vibe. Not a category. A specific thing.
Bad slide: "Our platform is built for scale and reliability."
Good slide: "Handles 40M events/day on 3 nodes. No database. No message queue."
Bad bullet: "Improved developer experience"
Good bullet: "Cut onboarding time from 3 days to 4 hours by replacing the config system"
If a slide can't be made specific because the user doesn't have the data yet, flag it explicitly and ask what they know. Don't invent specifics. Don't pad.
Writing Rules
These apply to all slide content generated by this skill.
Voice:
- Write the way a sharp person actually talks when they know their material
- Direct subject-verb-object sentences. Cut filler words.
- First person or second person is fine. Third person corporate narration ("The team leverages...") is not.
- Contractions are fine
Punctuation:
- No em dashes as a stylistic device. Use a period or a colon instead.
- Standard punctuation for slide content (periods, commas, colons, semicolons)
- Ellipses only if quoting someone
Emoji:
- Default to no emoji in slide content. Slides are not Slack messages.
- If the user's context makes emoji appropriate (casual internal talk, developer conference with a light tone), one per slide at most, and only where it's doing real work, not decorating.
- Never use emoji as bullet markers or to open a section header. That's visual noise, not design.
- Never use emoji to signal enthusiasm ("🚀 We're launching..." "✅ Key takeaway"). If the content is good, it doesn't need decoration.
Structural anti-patterns to avoid:
- Lists of three for rhythm ("fast, reliable, and scalable" — what does this mean?)
- Rhetorical question payoffs ("So what does this mean for you?")
- Fake dramatic fragments ("The result? Unprecedented growth.")
- Soft intensifiers ("quite", "really", "very", "fairly", "somewhat")
- Hedging openers ("It's worth noting that...", "It's important to understand...")
- "Not X, it's Y" constructions
- "Seamless", "robust", "leverage", "synergy", "unlock value", "move the needle"
- "Game-changer", "revolutionize", "transformative", "cutting-edge"
- Numbered insights ("3 Key Takeaways")
Bullet rules:
- Bullets must be substantive. Each bullet should contain a claim or a fact, not a category label.
- If a bullet can't be written without being vague, it means the underlying content isn't ready. Flag this.
- Parallel structure is fine if it's natural, not forced.
- 3-5 bullets per slide max. If you have more, split the slide or cut.
Workflow
Step 1: Understand the presentation
Before writing any slide content, ask or extract:
- Topic and audience — What is this about, and who is sitting in the room?
- Goal — What should the audience think, feel, or do differently after seeing this?
- Format — Conference talk? Internal team update? Customer pitch? Demo?
- Length — How many slides or how many minutes?
- What they already have — An outline? A rough draft? Just a topic?
If the user has already provided this context, don't re-ask. Use it.
Step 2: Build or review the structure
Before writing slide content, get the structure right. This means:
- An opening that establishes why the audience should care (not "About Me" slides that run for 5 minutes)
- A logical narrative arc (not a list of disconnected topics)
- A clear landing point — what is the last thing the audience hears/reads?
If the user already has a structure, critique it. Flag slides that are redundant, out of order, or missing.
Step 3: Write slide content
For each slide, produce:
Slide title — A declarative statement, not a noun phrase.
- Good: "Latency dropped 60% after we dropped the ORM"
- Bad: "Performance Improvements"
Slide body — The actual content: bullets, a key stat, a quote, a diagram description, code snippet description, or a single strong sentence.
Substance check — After each slide or section, note honestly whether the content is solid or whether it's relying on vague claims.
What to add — If a slide is thin, say so directly and list what specific information would make it stronger. Don't pad to compensate. Ask.
Step 4: Flag and prompt for missing substance
This is the most important part of the skill. When content is thin:
- Say it plainly: "This slide is making a claim without evidence. Do you have a specific number, example, or case that backs this up?"
- Suggest what kind of evidence would work: "A before/after metric, a specific user quote, or a concrete example would make this land."
- Never invent the missing content. Never soften the critique.
Step 5: Deck-level review
Once all slide content exists (either just written or provided by the user), do a full pass across the whole deck. This is separate from the per-slide substance check. Look at the deck as a sequence, not a collection.
Flow: Does each slide follow logically from the one before it? If you removed a slide, would the audience notice the gap? Flag any slides that feel disconnected or could be reordered without changing anything.
Engagement arc: Where does attention peak? Where does it sag? A deck that stays at the same energy level throughout loses the room. There should be a build, at least one payoff moment, and a clean landing. Identify where the deck is flat and suggest what type of content (a concrete example, a visual, a surprising stat, a demo moment) would re-engage.
Transitions: Flag slide pairs where the jump is abrupt. A transition problem usually means one of three things: a slide is missing in between, the order is wrong, or the title of one of the slides isn't doing its job. Suggest the fix specifically, not generically ("add a transition slide" is not useful — say what that slide should say).
Redundancy: Flag any slides that are making the same point twice in different words. Pick the stronger one. Cut the other or merge them.
Pacing: For timed talks, flag sections that look too dense for the time allocated. A technical deep-dive that would take 8 minutes crammed into a 2-minute slot is a structural problem, not a content problem.
Output the deck review as a separate section after the slide content:
## Deck Review
**Flow:** [What works, what doesn't, specific slide numbers]
**Engagement:** [Where it's strong, where it sags, what to try]
**Transitions:** [Specific pairs that are abrupt, suggested fixes]
**Redundancy:** [Any slides making the same point, recommendation]
**Pacing:** [If timing is relevant, any density issues]
**Priority fixes:** [Ranked list of the 2-3 changes that would most improve the deck as a whole]
If the deck is in good shape, say so. Don't manufacture critique. But if there are real problems, name them clearly with slide numbers and specific suggestions.
Slide Templates by Type
These are patterns, not formulas. Adapt to context.
Problem slide
State the problem in concrete terms. Not "teams struggle with X" — describe what actually happens when the problem occurs. Symptoms. Costs. Who feels it.
Solution slide
Lead with the mechanism, not the benefit. What does it actually do, and how? Benefits follow from that.
Results / proof slide
Specific numbers, real comparisons, before/after. If you don't have numbers, use a specific customer story with a named outcome.
Technical deep-dive slide
Pick one thing to explain. Don't try to show the whole system. Show the interesting part. A good diagram description or annotated code excerpt beats a wall of bullets.
Call to action slide
One ask. Concrete. With a clear next step (link, email, repo, sign-up, etc.)
Working with the Presentation Template
The user's template lives at github.com/charliecpeterson/presentation-template. It uses Quarto + revealjs. This skill handles content and layout design; the .qmd implementation is a separate concern.
Division of labor
- This skill (design): What goes on each slide. Narrative. Layout selection. Visual QA feedback. Deck-level review.
- Implementation (needs filesystem access): Writing the
.qmd file, running build.sh, rendering, taking screenshots. Do it in the same session if you have the tools; otherwise hand the slide plan to an agent that does.
Layout palette — match content to the right layout
Every slide should use a layout that fits its content. Don't default to full-width bullets on every slide. Varying layouts across the deck keeps the audience visually engaged. Here are the available layouts from the template — choose based on what the content actually needs:
| Layout | Quarto pattern | Best for |
|---|
| Two-column 60/40 | .columns 60/40 | Main content + callout, note, or image |
| Two-column 50/50 | .columns 50/50 | Side-by-side comparison, two parallel points |
| Three-column 33/33/33 | .columns 33/33/33 | Spectrum, tiers, phases — use .text-sm |
| Comparison A vs B | .highlight-box + .accent-box in 50/50 | Recommended vs legacy, right vs wrong |
| Stacked comparisons | Multiple A-vs-B rows | Several examples of the same contrast pattern |
| Numbered steps | .steps class in 60/40 | Sequential process with 3-5 steps |
| Step-by-step (prose) | Bold step headers in 60/40 | Process where each step needs explanation |
| Image + caption | Image in 60, bullets in 40 | Diagram, screenshot, or figure with callout |
| Big screenshot + bullets | Image in 55, bullets in 45 | Demo slides, showing something in action |
| Pull quote | .pull-quote in 65/35 | Key finding, paper result, memorable statement |
| Key metrics | .stat-row + .stat-card + table | Benchmark results, feature comparisons |
| Incremental reveal | . . . between bullet groups | Demos, walk-throughs, building suspense |
| Code slide | ```{.python/bash/r} in 60/40 with .slide-code | Code examples, CLI commands |
| Code + output | Code fence + ```{.output} | Showing command and its terminal result |
| Two-language comparison | 50/50 code blocks | Python vs Bash, etc. |
| Full-width single statement | No columns, .text-xl | Title-card moments, section payoffs |
Heading icon classes (append to ## Title {.class}):
{.slide-code} — CLI, code, API{.slide-data} — results, benchmarks, tables{.slide-compute} — hardware, GPU, resources{.slide-flow} — workflow, steps, process{.slide-cluster} — distributed, parallel, multi-node- no class — general content (most slides)
Callout types (always use
appearance="simple"):
.callout-note — general context (cyan border).callout-tip — best practice (green border).callout-warning — gotcha or prerequisite (red border).callout-important — critical requirement
Box types:.highlight-box — key takeaway (teal border, cyan background).accent-box — warning or caveat (red border, red background) — use sparingly.key-finding — auto-prepends "KEY FINDING" label, teal styling
Font size classes (never inline styles):.text-xl — sparse slides, key statements.text-lg — slides with less content.text-md — default for most content slides.text-sm — supporting detail, busy slides.text-xs — dense tables, attribution, fine print
Layout variety — engagement rule
Don't use the same layout more than two slides in a row. A monotonous deck loses the room even if the content is good. When writing slide content, note the suggested layout for each slide and flag if the deck has a long run of the same pattern. Suggest a different layout that fits the content.
Good layout variety across a 10-slide section: 60/40 content → comparison A/B → code slide → image + bullets → pull quote → metrics → steps → 60/40 content → full-width statement → 50/50
Visual QA with computer use
When computer use is available, Claude Code can render the deck and take screenshots. This skill should request a visual check whenever:
- A slide has an image, table, figure, or code block
- A slide is using three columns (cramped by default)
- A slide has more than 5 bullets or dense text
- A new layout is being used for the first time in the deck
How to trigger a visual check (instructions for Claude Code):
mkdir -p _screenshots/check
npx decktape reveal --screenshots --screenshots-format png \
--screenshots-directory $(pwd)/_screenshots/check \
--size 1280x720 "_output/presentation.html" slides.pdf
Then view each screenshot and assess:
What to check per slide:
-
Does all text fit inside the slide without overflow? If not: reduce bullet count, drop font size class one level, or split the slide.
-
Is the image/figure/table large enough to read from the back of a room? If not: increase width or max-height, or move to a full-column layout.
-
Do columns look balanced? A 60/40 with the 60 nearly empty and the 40 overflowing means the split is wrong.
-
Does the callout or box fit without clipping?
-
Is code readable? Blocks with more than ~12 lines need to be split or font-dropped to .text-sm.
Suggest fixes, don't silently adjust. If something doesn't fit, tell the user specifically what the problem is and offer options:
-
"The image on slide 8 is too small to read in the 40% column. Options: move the image to 60% and the bullets to 40%, or use the Big Screenshot layout (55/45) instead."
-
"Slide 12 has 8 bullets. It's overflowing the slide. Suggest: cut to the 4 most important, or split into two slides — first covering X, second covering Y."
-
"The three-column layout on slide 6 is cramped. If the content can't be cut, consider splitting it into two 50/50 comparison slides instead."
Never make layout changes silently. Always present the issue and ask the user how they want to handle it.
Handoff to Claude Code
A complete handoff from this skill to Claude Code includes:
- Slide number, title, and body content written out
- Suggested layout for each slide (from the palette above)
- Suggested heading icon class if applicable
- Callout type and content if one is needed
- Notes on images, code blocks, or special elements
- Any speaker notes or timing notes
- After rendering: a list of any visual QA issues and proposed fixes
Anti-Patterns Reference
Keep this in mind when reviewing or generating any slide content.
| Pattern | Why it's bad | Fix |
|---|
| "It's important to note..." | Implies the rest isn't important | Just say the thing |
| "Seamless integration" | Meaningless without specifics | Describe the actual integration |
| Em dash as a stylistic pause | AI tell, reads as performed writing | Use a period or colon |
| Three-word list for rhythm | Sounds like marketing copy | One strong specific beats three vague ones |
| Rhetorical question setup | Lazy structure | State the answer directly |
| "Not X, it's Y" | Overused contrast device | Just say Y |
| Dramatic fragment | "The result?" | Roll it into the preceding sentence |
| Soft intensifier | "quite significant" | "significant" or give the number |
| Category bullet | "Improved performance" | "Query time: 800ms to 120ms" |
| Emoji as bullet markers | Visual noise, not design | Use plain bullets with substantive text |
| Emoji for enthusiasm | "🚀 We're launching" | Let the content carry the energy |
Output Format
When producing slide content, use this format:
## Slide N: [Title] {.optional-icon-class}
**Layout:** [Which layout from the palette, e.g. "Two-column 60/40 with callout-tip"]
[Body content — bullets, stat, quote, or description, written for that layout]
**Substance check:** [Honest assessment of whether this slide is solid]
**Could add:** [Specific things that would make it stronger, if applicable]
For a full deck, group slides into sections if the deck has a natural arc. After all slides, append the Deck Review block (see Step 5).
Tone Calibration by Audience
Technical audience (engineers, researchers):
- Mechanism first, benefits second
- Specifics over summaries
- It's fine to leave things unexplained if the audience knows them
Executive / business audience:
- Outcome first, then evidence
- Still specific — just use business metrics instead of technical ones
- Cut jargon, not substance
Mixed audience:
- Lead with the outcome
- One slide of technical proof, clearly labeled
- Avoid assuming shared vocabulary
Quick-Start Prompts
If the user is starting from scratch, offer to run through these:
- What's the one-sentence version of what you want the audience to know by the end?
- What do they probably believe right now that you want to change?
- What's the most surprising or counterintuitive thing you're going to say?
- What's the single strongest piece of evidence you have?
The answers to these four questions contain the skeleton of a good talk.
