Visual HTML Presentations

intent

create polished, self-contained HTML presentations that open locally in a browser, work in meetings, record in videos, or serve as a starting point for later design work. use this skill when a user asks to create, improve, or convert content into a presentation, deck, slides, slideshow, pitch deck, class, workshop, training, explainer, or any browser-ready visual presentation. trigger examples: "make a presentation", "create a deck", "turn this into slides", "make this visual", "prepare slides", "improve this presentation", "create an html presentation". do not use this skill when the user explicitly wants an editable design file, a branded template workflow, real-time collaboration in a design app, or a specific export format (pdf, pptx, figma) that a local html deck cannot provide.

inputs

user content (required)

• idea, notes, outline, document, transcript, markdown, report, or existing deck content in any readable form.

clarification details (optional, ask if missing and material)

• audience and their technical level or context.
• objective or primary call to action.
• slide count or time budget (e.g. 5-minute talk, 10-slide deck).
• brand, style, or tone requirements.
• whether output must be editable in another tool or exported to a specific format.

context flags (optional)

• intended use case: video/screen recording, in-person meeting, training/workshop, investor pitch, educational content, or other.
• any existing brand colors, fonts, or design constraints.
• whether speaker notes or printed output is needed.

external data (optional)

• urls, images, charts, or diagrams to embed (only if user provides or approves).
• citations, sources, or fact-check requirements for public-facing or high-stakes decks.

procedure

1. read and extract: consume the full input. identify topic, objective, audience, key message, required facts or sources, desired tone, use case, and approximate slide count. note any missing details that materially affect the result.

2. ask or assume: if audience, objective, slide count, brand, or export requirements are unclear and impact the outcome, ask short clarification questions. if missing details are minor, assume reasonably and state assumptions in the summary.

3. build narrative structure: map the logical flow from opening (title slide) to context or problem, main ideas, examples or evidence or process, implications or recommendations, and closing or call to action (when relevant). keep one main idea per slide.

4. choose visual style: select a design approach suited to the topic and audience. consider: color palette (restrained, subject-appropriate), typography (clear hierarchy, legible body text), layout variety (avoid repetitive patterns), and tone (professional, casual, academic, creative).

5. design slide layouts: create a mix of appropriate patterns including title slide, two-column concept/explanation, large number or key metric, timeline or roadmap, step-by-step process, comparison, quote or principle, diagram or architecture, problem/solution, and summary or cta. vary layouts to maintain visual interest.

6. generate html, css, javascript: build a single self-contained html file with embedded css in <style> tags, embedded javascript for navigation, keyboard support (left/right arrow keys), visible previous/next controls or slide dots, print-friendly css when practical, and responsive constraints so text does not overflow. do not rely on remote images or fonts unless user explicitly requests and accepts the tradeoff.

7. validate locally: confirm that slides render correctly, text fits containers, navigation works with keyboard and buttons, layout is not blank or overlapping, and narrow viewports do not break badly. note if visual verification cannot be run.

8. deliver result: return summary (objective, audience, style chosen), structure (slide titles in order), result (local file path or inline html), verification (what was checked), and remaining items (missing assets, sources, improvements).

decision points

if clarification is needed and material: ask short questions about audience, objective, slide count, brand, or export format before building. do not proceed if the answer significantly changes the output. state any assumptions you make and continue.

if clarification is missing but minor: assume reasonably (e.g. assume general business audience if not specified) and note the assumption in the summary. proceed without asking.

if user requests editable design file, branded template workflow, real-time design collaboration, or specific export format (pdf, pptx, figma, keynote): recommend a dedicated design tool instead. do not force html output if the user's true need is incompatible with a single-file html deck.

if user provides brand, project, or organization context: follow provided style guidance. avoid unsupported claims or invented references. keep tone appropriate to audience. recommend factual claim check for public, investor-facing, medical, legal, financial, or high-stakes decks. do not publish, upload, or share externally without explicit user approval.

if slides are for video, reels, screen recording, or narration: use fewer words per slide, stronger visual rhythm, large type, clear contrast, one sentence or one idea per slide, avoid dense bullet lists, and consider 16:9 layout unless otherwise requested.

if slides are for meeting, class, workshop, or training: prioritize clarity over spectacle, include slide numbers, allow slightly more detail per slide, use summary slides and section breaks, and include speaker notes only if explicitly requested.

if user asks for remote images, fonts, or assets: only include if user explicitly requests and understands the tradeoff (requires internet to view, slower load, harder to share offline). prefer local assets by default.

if slide deck is large (>15 slides): do not paste full html into chat unless user asks. create and reference the local file instead.

if text or visual elements do not fit or render incorrectly: adjust font size, layout, or slide structure. repeat validation until acceptable.

if user requests safety or sensitive content check: ensure the skill does not upload, publish, share, or send the result through external services unless explicitly requested and approved.

output contract

file location: presentations are stored locally by default (e.g. ./presentation.html or user-specified path) unless user requests another destination.

file format: single self-contained html file with inline css and javascript. no external dependencies unless user explicitly approves.

structure and content:

• proper html5 doctype, semantic markup, and valid css.
• slide narrative matching the original input's key points, in logical order.
• one main idea per slide with clear title and supporting text or visuals.
• layout variety using appropriate patterns (title, two-column, metric, timeline, process, comparison, diagram, summary).
• navigation via keyboard arrows (left/right), visible previous/next buttons, and optional slide dots or counter.

visual standards:

• responsive constraints so text does not overflow on common laptop and desktop screens.
• restrained color palette suited to subject and audience.
• clear visual hierarchy (title, supporting text, visual structure).
• varied layouts across slides, not repetitive.
• no decorative blobs, generic gradients, or stock-like filler visuals unless subject requires.
• icons, numbers, timelines, diagrams, comparison blocks, or process flows when they clarify ideas.
• legible body text with strong spacing and alignment.
• no invented data, citations, logos, brand claims, or source references.

delivery package:

• summary: objective, audience assumption, style chosen.
• structure: list of slide titles in order.
• result: local file path or inline html (for small decks or if user requests inline code).
• verification: what was checked (rendering, navigation, text fit, layout integrity, viewport behavior).
• remaining: list of missing assets, sources, brand details, or optional improvements.

outcome signal

the user knows the skill worked when:

1. file exists and opens: the html file renders correctly in a modern browser without errors or external dependencies missing.

2. slides navigate: keyboard arrows (left/right) and visible controls (buttons or dots) move between slides smoothly. no blank screens, overlaps, or navigation breaks.

3. content fits: all text is legible and contained within slide bounds. no overflow, truncation, or readability issues on common screen sizes (laptop, desktop, and reasonably narrow viewports).

4. visual is attractive and clear: layout variety, color palette, typography, and use of visual elements (icons, diagrams, spacing) make the deck visually coherent and easy to follow. one main idea per slide is evident.

5. style matches intent: the design reflects the chosen style (professional, casual, academic, creative, etc.) and suits the audience and use case (video, meeting, training, pitch).

6. summary confirms match: the delivered summary (objective, audience, style) and structure (slide titles) match or clarify the original user request. any assumptions or missing details are stated.

7. user can re-use or edit: for html-savvy users, the single-file structure and inline css/js make it easy to tweak colors, text, or layout. for others, the file is ready to present, record, or share as-is.