Slides Skill

Use this skill to create reusable, high-signal slide decks in a single self-contained HTML file.

The goal is not to make generic slides. The goal is to turn a subject into a sharp presentation with a clear thesis, disciplined pacing, persuasive structure, and portable vanilla implementation.

Core defaults

• Default to one self-contained HTML file with inline CSS and JavaScript.
• Do not use Google Fonts or any external font dependency.
• Prefer system font stacks and ui-monospace style stacks.
• Build decks that are easy to move around, open locally, and present without a build step.
• Preserve the feeling of a crafted keynote: strong openings, meaningful transitions, visual variety, and concise takeaways.

When to clarify vs when to proceed

First assess whether the user has provided enough context.

Proceed directly if the prompt already gives most of these:

• subject
• audience
• purpose
• approximate depth or length
• any requested tone or visual direction

If the prompt is vague, start a short dialogue to gather only the missing high-value context.

Prefer asking about:

1. subject or thesis
2. audience
3. purpose of the presentation
4. desired length or number of slides
5. tone and color direction, if relevant

Do not over-interview. If you can infer reasonable defaults, do so and continue.

Planning the deck

Before writing slides, define the presentation strategy.

Extract or infer:

• the central thesis
• the audience's likely context
• what the audience should understand, feel, or do by the end
• the main tension, problem, or opportunity
• the strongest evidence types for this topic: examples, diagrams, comparisons, metrics, code, quotes, scenarios

Then decide what kind of deck it is. Common modes:

• technical explainer
• persuasive pitch
• strategy or vision deck
• product overview
• architecture or implementation briefing
• status update or report-out
• educational workshop talk

Use that mode to bias the slide mix, but keep the structure flexible.

Narrative principles

Build a deck with a narrative arc, not a pile of bullet points.

Good default arc:

1. title / framing
2. agenda or orientation
3. problem, tension, or stakes
4. goal, thesis, or promise
5. explanation of the mechanism or core idea
6. architecture, model, or workflow
7. examples / use cases / proof
8. limitations, tradeoffs, or objections
9. implementation status or practical next steps if relevant
10. conclusion and memorable closing

Treat these as slide roles, not mandatory headings. Adapt them to the topic.

Content quality rules

• Optimize for signal density, not maximum text.
• Each slide should have one primary job.
• Keep headlines declarative and meaningful.
• Use supporting text to clarify, not to repeat the title.
• Prefer comparisons, diagrams, timelines, stat blocks, and scenario framing over long bullet dumps.
• Include honest limitations when the topic benefits from credibility.
• End with a distilled thesis or memorable line, not a weak generic wrap-up.

Visual and interaction system

Mirror the presentation philosophy of the reference deck while staying topic-agnostic.

Preferred ingredients:

• dark background with restrained accent colors
• strong typography hierarchy
• glassy or low-contrast cards
• mono styling for technical elements, timers, tags, and code
• diagram boxes for architecture, flows, and structured text visuals
• tags or pills for categorization and emphasis
• stat boxes for big numbers or high-level claims
• tables for standards, comparisons, or phases
• timelines for sequences, migrations, or maturity curves
• staggered reveal items where they improve pacing

Reusable interaction features:

• previous / next navigation
• keyboard controls
• touch swipe support
• progress or timer bar
• slide counter
• optional presenter notes toggle
• optional presentation timer

Only include features that support the deck. Keep the file simple and dependable.

Implementation guidance

When generating the HTML deck:

• Keep HTML, CSS, and JavaScript inline unless the user explicitly asks for split files.
• Use semantic sections and clear class names.
• Keep the code readable enough that a human can edit the deck later.
• Make the layout responsive for laptop screens and smaller displays.
• Avoid unnecessary framework-style complexity.

Font guidance:

• Use system UI stacks for body and headings.
• Use ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, Liberation Mono, or similar fallbacks for code-like text.
• Never import external fonts by default.

Adaptation rules

If the user specifies tone, adapt copy and visuals accordingly:

• visionary: larger claims, stronger emotional framing, bolder closing
• technical: tighter language, more diagrams, more implementation detail
• executive: fewer slides, clearer stakes, stronger summaries
• educational: more scaffolding, clearer transitions, gentler ramp-up
• activist or values-driven: stronger framing, principles, consequences, calls to action

If the user specifies color direction, adapt the palette while preserving contrast and readability.

If the user gives no visual preference, use the dark cinematic default.

Output expectations

Default output:

• one portable HTML file ready to open locally in a browser

The final response should usually include:

• a short summary of the presentation strategy
• the generated HTML file
• brief notes on how the deck is structured, if helpful

Resource usage

If you need a deeper reminder of the design language, read presentation-principles.md.

If you need a clean implementation starting point, read single-file-slide-template.html.