Presentation Designer

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:

1. Topic and audience — What is this about, and who is sitting in the room?
2. Goal — What should the audience think, feel, or do differently after seeing this?
3. Format — Conference talk? Internal team update? Customer pitch? Demo?
4. Length — How many slides or how many minutes?
5. 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. Claude Code handles the actual .qmd file, rendering, and code.

Division of labor

• This skill (Claude.ai): What goes on each slide. Narrative. Layout selection. Visual QA feedback. Deck-level review.
• Claude Code + template: Writing the .qmd file, running build.sh, rendering, taking screenshots.

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:

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):

# Screenshot all slides for review
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.

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:

1. What's the one-sentence version of what you want the audience to know by the end?
2. What do they probably believe right now that you want to change?
3. What's the most surprising or counterintuitive thing you're going to say?
4. What's the single strongest piece of evidence you have? The answers to these four questions contain the skeleton of a good talk.