Html Slide

HTML Slide — Keynote-Grade HTML Presentation Generator

Build presentation decks as a single self-contained HTML file: no build step, no framework, no CDN-critical dependency. Open in any browser and present with arrow keys. The output should look like it was designed by a keynote design studio, not assembled from a Bootstrap template.

Why this skill exists (the two defects to kill)

Naive HTML slides fail in two predictable ways. Every rule in this skill traces back to one of them:

1. Text is too small. Web-page habits (16-24px body) leak into slides.

A slide is read from meters away, projected or shrunk into a video call tile. Slide typography starts where web typography ends.

1. Boxy template sameness. Centered title + three equal cards + bullet

list, repeated N times, in Inter on a purple-gradient background. The fix is committed art direction: one distinctive theme, layout variety, and typography as the hero.

Positioning vs sibling skills

| Deliverable | Skill | |-------------|-------| | HTML deck (browser, animation, single file) | this skill | | PPTX (PowerPoint, AWS-themed) | myslide | | Standalone SVG diagram/banner | svg-diagram | | AWS architecture diagram | aws-diagram |

If the user says "슬라이드 만들어줘" without a format, ask once — HTML (animated, browser) vs PPTX (editable, corporate). If they mention motion, web, or "임팩트", default to HTML.

Quick Start

1. Gather topic, audience, slide count, language (Korean/English/mixed) —

and ask the AWS-branding + presenter questions (see § AWS Branding) in the same breath

1. Pick a theme from [references/themes.md](references/themes.md) and

customize it to the topic (accent color, display font, texture) — presets are starting points, never final answers

1. For 6+ slides, write a 1-screen design spec first (table: # / layout /

grammar / key message / effect) and get user approval — structural rework is the expensive kind

1. Build the deck on the engine skeleton in

[references/engine.md](references/engine.md) — read it before writing any HTML; it contains the scaling, navigation, steps, and print machinery that must not be reinvented

1. Choose layouts per slide from [references/layouts.md](references/layouts.md)

respecting the Mix Rule (below)

1. Add 2-3 signature effects from [references/effects.md](references/effects.md)

— including the Apple-style reveal templates when the deck introduces a product/feature

1. Run the QA checklist (below), then deliver the single .html file

Typography Contract (CRITICAL — this is the "small text" fix)

All sizes are px on the fixed 1920×1080 stage. The engine scales the whole stage, so these are effectively viewport-proportional. Rule of thumb for translating presentation-industry pt guidance: 1pt ≈ 2px @1080p (PowerPoint's 13.33in canvas mapped to 1920px) — so the classic "24pt body minimum, Kawasaki's 30pt gold standard" lands at 48-60px here.

| Role | Size | Weight / notes | |------|------|----------------| | Deck title (title slide) | 112–176px | 700-800, line-height 1.02-1.08, letter-spacing -0.02em to -0.04em | | Hero statement / big claim | 88–128px | one sentence max | | Hero stat ("80%", "3x") | 280–420px | gradient or accent color | | Section numeral ("01") | 240–360px | the numeral IS the visual | | Slide heading (h2) | 64–80px | ≤ 2 lines | | Subheading / lead | 40–48px | | | Body & bullets | 36–48px, absolute minimum 30px | line-height 1.5-1.6 (Korean: 1.6-1.7) | | Code | 28–32px monospace | ≤ 14 lines per slide | | Eyebrow label | 22–28px | uppercase, letter-spacing 0.12-0.2em | | Caption / footer / page number | 20–24px | this is the ONLY place ≤ 24px is allowed |

Use ≤ 3 text sizes per slide, stepped on a modular scale (×1.25 Major Third or ×1.333 Perfect Fourth) rather than ad-hoc values — e.g. 36 → 48 → 64 → 80. Prefer the upper half of the body range for keynote/ exec decks; the lower half is for dense engineer content.

Text budget: one idea per slide. Heading ≤ 2 lines. Body ≤ 5 bullets or ≤ 60 words. If content doesn't fit at minimum sizes, split the slide — never shrink the font. Body text column ≤ 62% of stage width (readability, not timidity).

Why the fixed stage matters: the browser's default 16px body is the root cause of tiny slide text — the viewport grows but web-document type does not. On the fixed 1920×1080 stage every px is a design px, so the contract above holds identically on a 14" laptop, a projector, and a video-call tile. Never use rem/vh/vw or browser-default sizes inside slides.

Space Budget (the "empty box" fix)

The sibling defect of small text: boxes drawn content-fit around small type, leaving the stage mostly dead space (or, inverted, a giant box with a lost caption inside). Rules:

• Content covers 60-80% of the stage area on standard content slides.

Below 60%: scale typography up or enrich the layout — don't leave accidental voids. (Deliberate Big-Statement slides are the exception: their emptiness is designed, not leftover.)

• Boxes are sized by the layout grid, not by their content. A card in

a 3-card row is 1/3 of the content band, full height — text fills the card, not the reverse. Sibling cards share identical dimensions (grid 1fr), never shrink-wrapped individually.

• Whitespace goes to margins and gutters (page margin 96-120px,

gutters 32-48px), not trapped inside or between boxes randomly.

• Fill ratio check: eyeball each slide at thumbnail size — if it reads as

"small text island in a dark ocean", the space budget failed.

Korean text: word-break: keep-all; line-break: strict; on every text container (plus overflow-wrap: break-word as a long-token safety valve). Default Korean-capable stack: Pretendard (CDN with system fallback). Korean is full-width square glyphs — give body text MORE leading than Latin (1.6-1.7 vs 1.5) but tighten Korean display headlines to 1.15-1.25; Korean display also reads ~5% larger than Latin at equal px.

Text budget headline rule: write slide titles as action titles — full-sentence conclusions ("추론 비용이 구조적으로 꺾였습니다"), not topic labels ("비용 현황"). The title should pass the glance test: reading titles alone tells the deck's whole story.

Korean tone — default to 존댓말 (honorific/polite) everywhere. This is the presenter speaking to an audience of customers and colleagues, so slide copy carries the same courtesy as the spoken talk. Titles, headings, body, captions, and closing lines all use polite endings (-습니다/-합니다/-됩니다, noun phrases, or the polite 요-form) — the emphatic plain form (반말: 꺾였다 / 결정한다 / 움직이고 있다 / 제품이다) reads as terse and is the one place naive slide copy most often slips, especially in punchy action-title headings where the plain form feels stronger. It isn't: an honorific action title ("추론 비용이 구조적으로 꺾였습니다", "런타임이 결정합니다", "현장은 이미 움직이고 있습니다") lands with the same conviction and matches the room. Short noun-phrase labels ("비용 현황", "도입 로드맵", "세 가지 통합 패턴") stay as-is — they read as neutral captions, not clipped sentences, so they don't need a verb ending. Switch to plain form only when the user explicitly asks for it (a punchy 반말 brand voice, a quote that was actually said in 반말). English copy is unaffected.

Korean naturalness — run a translationese sweep on every Korean deck. Tone (존댓말) being correct doesn't make the copy natural: the most common field correction on Korean decks is not grammar but 번역투 — phrasing that is a literal carry-over from the English tech idiom the deck was drafted in. Users consistently rewrite these, so catch them before delivery. The recurring offenders, all field-corrected at least once:

| Pattern | Example (bad → good) | Why it fails | |---------|----------------------|--------------| | Untranslated jargon transliterated | 노브(knob) 총정리 → 튜닝 포인트 총정리 / 조정 항목 | English-community shorthand ("knobs to tune") means nothing to a Korean audience; find the concept, not the word | | Direct calque of an English idiom | 세 가지 축이 전부입니다 ("three axes is all") → 세 가지만 기억하시면 됩니다 | Grammatical but nobody says it; rewrite as what a presenter would actually say | | Stiff Sino-Korean compound where a plainer phrase exists | 데이터 상주(residency) 요건 → 데이터 저장 요건 / 국내 데이터 저장이 필요한 | Direct dictionary translation of a compliance term reads bureaucratic; prefer the phrase Korean engineers use in conversation | | Same concept, two Korean renderings in one deck | slide A "재순위화", slide B "리랭킹" → pick one (리랭킹) and keep it | Audiences read term changes as concept changes; do a find-pass for every loanword-vs-번역어 pair (리랭킹/재순위, 청킹/분할, 임베딩/벡터화…) |

The test for each suspicious phrase: "발표자가 무대에서 이 문장을 소리 내어 말한다면 자연스러운가?" If you'd never hear it spoken at a Korean tech conference, rewrite it — meaning first, word second. When a term is genuinely ambiguous (loanword vs 번역어 both plausible), prefer the form the AWS Korean documentation/blog uses, and keep it consistent deck-wide.

This sweep is cheap: after the deck is drafted, re-read only the Korean strings (titles → labels → body, in that order — titles are the most visible and the most prone to calques because action-title pressure invites literal translation). Fix in place before the visual QA pass.

Theme Selection (preset + mandatory variation)

Full tokens in [references/themes.md](references/themes.md).

| Theme | Mood | Default for | |-------|------|-------------| | Midnight Keynote | near-black, huge white type, one gradient accent | product launch, keynote, "임팩트" requests | | Aurora Tech | deep navy, aurora gradient mesh, glassy cards | AI/cloud tech talks, demos | | Paper Editorial | warm paper, serif display, ink text | strategy, storytelling, exec audience | | Swiss Minimal | white, grid-visible, one hard accent | data-heavy, portfolio, design review | | Terminal Mono | CRT dark, monospace, scanline texture | engineering deep-dive, CLI/devtools |

Variation is mandatory: change at least accent color + display font pairing to fit the topic before building. Two decks from this skill should never look identical. Keep each deck to ≤ 5 colors total (bg, surface, text, muted, accent — gradient stops count as one accent family).

Never: Inter/Roboto/Arial as display font, purple-gradient-on-white, default blue links, five competing accent colors.

Layout Grammar & Mix Rule

Layout catalog with copy-paste HTML in [references/layouts.md](references/layouts.md): Title, Section Divider, Big Statement, Hero Stat, Two-Column Asymmetric (35/65), Bento Grid, Card Row, Quote, Timeline/Steps, Comparison, Code Walkthrough, Image Full Bleed, Closing, plus card-free layouts (Ledger List, Indexed Definitions, Split Contrast) and chart layouts (Bar Chart, Donut/Pie + KPI).

Mix Rule (inherited from myslide, field-proven): never repeat the same layout 3+ times in a row. Centered-symmetric layouts count as one implicit grammar — break runs with an asymmetric split, a bento, or a margin-heavy statement slide. In an 8+ deck use at least 4 distinct layouts.

Surface-variety rule: rounded .cell cards dominate the Bento, Card Row, Comparison, and Code layouts — reach for them every slide and the deck reads as repetitive grey boxes even when the Mix Rule passes. Use card layouts at most twice in a row; make the third information group card-free (Ledger List, Indexed Definitions, Split Contrast, Two-Column) or a chart.

Decoration discipline: typography and structural blocks are the visual hero. Add decoration only where it carries information (a CTA band, a section numeral). No random orbs, no thin gradient strips on every slide, no icon confetti.

Visual Effects (the "임팩트" layer)

Full library with code in [references/effects.md](references/effects.md). Two categories:

Slide-enter builds — fire when a slide becomes active: staggered rise, blur-reveal (Apple product-shot style), gradient headline shimmer, count-up stats, mask wipe, Ken Burns on full-bleed images, product settle (scale 1.06→1 + shadow bloom).

In-slide steps — data-step elements revealed one keypress at a time, enabling Apple-style pinned storytelling: one persistent object on stage whose state (transform/label/highlight) changes per step, like apple.com's scroll-pinned product sections translated to keypress phases.

Restraint contract:

• Pick 2-3 signature effects per deck and reuse them consistently —

every-slide-different-effect reads as chaos, not craft

• One easing everywhere: cubic-bezier(0.16, 1, 0.3, 1), entrances

600-900ms, steps 300-500ms

• Every effect must respect prefers-reduced-motion (engine handles the

global kill-switch; don't bypass it)

• Effects never gate content: with JS disabled or motion reduced, the deck

must still show all content (animate FROM an offset TO the natural state, never the reverse)

AWS Branding (ask before building)

Most decks from this skill represent AWS field work, but the right amount of branding depends on who's in the room. Three modes — which one applies is the user's call, not yours:

| Mode | What it means | Typical use | |------|---------------|-------------| | customer-session | Official AWS deck treatment: AWS-style cover + branded footer on every other slide | SA customer sessions, Summits, workshops | | logo-only | Smile logo on the title slide top-left, nothing else | decks that want identification without ceremony | | none | no AWS marks | non-AWS topics, internal scratch decks |

Ask once, up front. During requirements gathering fold both branding questions into the one AskUserQuestion call from Quick Start step 1:

1. "AWS 브랜딩을 어떻게 할까요?" — options: AWS 고객 세션 덱

(recommend when the audience is customers), 로고만, 없음.

1. Presenter name & role (drives the cover's presenter block and the

closing slide) plus the presentation date. Never assume a presenter: ask for the name and the title/role as free-form input — there is no preset default person — and default the date to today (YYYY-MM-DD).

Skip a question when the request already answers it ("로고 넣어줘" → logo-only, "고객 세션용이야" → customer-session, "로고 없이" → none; presenter named in the prompt → use it; date in the prompt → use it, else today). In unattended runs (subagent, eval, headless) default to none and omit the presenter block unless the prompt names a presenter — a missing logo or credit is a smaller error than an unwanted or wrong one — unless the prompt itself picks a mode.

Assets & embedding (single-file rule still holds)

| File | For | |------|-----| | assets/aws-logo-white.png | dark themes — Midnight Keynote, Aurora Tech, Terminal Mono | | assets/aws-logo-dark.png | light themes — Paper Editorial, Swiss Minimal |

Official artwork — never substitute look-alikes, redraw the smile, recolor, stretch, or add glow/shadow. Aspect ratio ≈ 5:3 (800×478); size by width only, and keep the logo on a background it reads on (white logo needs a dark region beneath — watch full-bleed images).

Inline the ONE variant the theme needs as a base64 data URI (base64 -i /assets/aws-logo-white.png | tr -d '\n'), defined exactly once as a CSS custom property. This matters in customer-session mode: the footer repeats on every slide, and repeating a ~70-100KB URI per slide is the fastest way to blow the 2MB budget.

:root { --aws-logo: url("data:image/png;base64,…"); }  /* define ONCE */

logo-only placement

• Title slide: top-left, aligned to the 96-120px page margin, width

150-190px. This is the canonical spot; it also frees the bottom for presenter credit.

• Content slides: nothing, or quiet footer level — bottom-left, width

100-130px, opacity .85. Never inside the content band.

• Closing slide: may sit above/beside the contact line, same size as title.

customer-session anatomy (lineage: official AWS PPTX decks)

Cover slide mirrors the AWS deck cover — five fixed elements, s

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: jesamkim
• Source: jesamkim/oh-my-skills
• License: MIT

Install and usage instructions live in the source repository linked above.