Slide Design

Slide Design

Create presentations with brand colors, typography, and assets baked in from the start, instead of picking a generic style and then replacing everything later.

This skill wraps two engines. It adds a brand setup phase before handing off to the engine's own workflow.

Phase 0: Source Discovery

Read the full source markdown end-to-end before touching anything else — brand setup included. This is the cheapest insurance against building the wrong deck. State explicitly in chat what you are treating as slide content vs. speaker notes vs. internal scaffolding, then confirm with the user via AskUserQuestion BEFORE generating any HTML. Even one round of "what's the source structure here?" beats a full rebuild.

0.A — Detect multi-section structure

Working drafts often split each slide into multiple sections by emoji or comment headers, and the LLM will cheerfully pull from all sections into the projected slide unless you intervene. This is the single most damaging silent failure for /slide-design — speaker notes get printed on the slide. Common patterns:

• 4-emoji split (very common in Chinese decks): **📝 這頁要做什麼** (meta description, NOT for slide) · **💻 ...** (live-demo state, NOT for slide) · **🖥️ 簡報文案** (THIS is slide content) · **📢 講稿** (speaker notes, NOT for slide)
• 2-section split: ## Slide + ## Notes, or <!-- slide --> + <!-- notes -->
• YAML frontmatter sections: slide:, notes:
• Bracketed inline annotations: [looks at audience], [pause here], （停頓）

If detected, ask the user explicitly: "Which section(s) go on the slide? Other sections are speaker notes / internal scaffolding?" Default to the most slide-like section name (🖥️, slide:, etc.) but CONFIRM before building. If the source is plain markdown with no sectioning, treat all body content as slide-eligible — don't invent the structure.

0.B — Strip internal scaffolding

Working drafts often label slides with planning scaffolding the audience never sees. The LLM treats these as part of the slide title or eyebrow; they are NOT. Strip before generation:

• Story-arc / framework tags — Act N · 平凡世界, Hero's Journey: Crossing the Threshold, narrative beats
• Slide IDs / version codes — v4-X, slide-42, r6-draft-3
• Time estimates and pacing notes — · 1.5 min, · 30 sec, (2 min)
• Speaker action meta — "ask the room", "transition to next", "pause", "現場調查", "自我介紹", "情緒高峰 #1", "橋接到下一頁"
• Author comments / TODOs / revision tags — R6 c4, R5 c12, TODO:, <!-- ... -->
• Section-divider intent — section headings like # Act 1 may be grouping markers in the source, not actual slides. Confirm with the user before auto-generating divider slides — those are a design choice, not source content.

0.C — Single confirmation gate

Before moving to Phase 1, package the above into one AskUserQuestion: (a) which section is slide content (if multi-section), (b) confirmation that the scaffolding above will be stripped, (c) whether section-divider slides should be auto-generated. One round is sufficient; skip entirely if the source is plain markdown with no structure.

Phase 1: Brand Setup

After source scope is confirmed, gather brand context. Ask these in a single AskUserQuestion call:

Question 1 — Brand Colors (header: "Brand"): How do you want to set定品牌色？

• "I have a design system file" — give me the path, I'll extract colors
• "I'll give you hex codes" — primary + secondary + background
• "No brand, use a preset" — fall through to the engine's default style picker

Question 2 — Assets (header: "Assets"): Do you have character images or background art?

• "Yes" — give me the folder path, I'll scan for usable images
• "No" — skip, use CSS-only visuals

Question 3 — Engine (header: "Engine"): Which engine do you want to use?

• "frontend-slides (Recommended)" — single HTML file, zero dependencies, animation-rich, scroll-based
• "reveal.js" — arrow-key navigation, fragment animations, speaker notes, vertical slide stacks, Chart.js

Processing Brand Input

If design system file is provided:

1. Read the file
2. Extract color tokens — look for hex codes, RGB values, or CSS custom properties
3. Map to presentation variables:
   • Darkest background color → --bg-primary / --background-color
   • Primary accent (often the brand's signature color) → --accent / --primary-color
   • Secondary accent → --accent-secondary / --secondary-color
   • Text colors (light for dark themes, dark for light themes)
4. Confirm with the user: "I found these brand colors: [show swatches]. Look right?"

If the design system describes colors in prose only (no hex codes):

• Ask the user to provide hex values directly
• OR sample from provided reference images (read images, pick from dominant tones)

If assets folder is provided:

1. Scan for image files (png, jpg, svg, webp)
2. View each image using the Read tool (Claude is multimodal)
3. Categorize: logo, character, background art, screenshot, other
4. Suggest placement: "I found [N] usable images. Here's how I'd use them: [list]"
5. Confirm with the user

SVG logo tinting trick

If you have a black / single-color SVG logo and want to match the brand primary color, use a CSS filter chain (no SVG editing needed):

.brand-mark {
  filter: brightness(0) saturate(100%) invert(77%) sepia(15%) saturate(1250%) hue-rotate(357deg) brightness(92%) contrast(87%);
  /* This chain tints black to ~#CD9D4F (warm gold). */
}

Use codepen.io/sosuke/pen/Pjoqqp or hex-to-css-filter to generate a chain for any target color.

Phase 1.5: Typography Scale

Apply a projection-optimized typography scale before writing any slide-specific CSS. See references/typography-scale.md.

Key rules:

• Any text the audience must read ≥ 17px. Use --fs-body-md as the floor for readable content.
• --fs-micro is for decoration only (slide numbers, step counters). Never for content.
• Define all 8 tokens in :root so slides can reference them consistently.

After brand colors + typography tokens are in place, move to Phase 2.

Phase 2: Hand Off to Engine

After brand + typography setup, invoke the appropriate skill:

• frontend-slides: Use the frontend-slides skill, but skip its Phase 2 (style discovery) — you already have the brand colors. Jump straight to Phase 3 (generation) with the brand palette pre-applied. For atmosphere (corner glows, scene illustrations, character cameos), apply the layered backdrop system — see references/backdrop-system.md.
• reveal.js: Use the revealjs skill. Generate the scaffold, then customize styles.css with the brand colors before filling in content. Use Google Fonts or Fontshare instead of system fonts.

In both cases, pass through all brand colors, typography tokens, and asset paths so the engine uses them from the start.

Phase 2.5: Icon System (Replace Emoji)

If the deck uses emoji as functional pictograms (pipeline icons, status markers, stage glyphs), replace them with vector icons from an inline SVG sprite. Emoji render fuzzy on projectors and differ per OS. See references/icon-system.md.

Three things matter:

• Default .icon-svg { width: 1em; height: 1em } — browsers render <svg> without size at 300×150px; this one rule prevents every icon from exploding
• Phosphor Icons via CDN — cdn.jsdelivr.net/npm/@phosphor-icons/core@2.1.1/assets/regular/<name>.svg
• Sprite pattern — one <symbol> per icon inside a top-of-body hidden <svg>, referenced via <use href="#icon-name">

Skip this phase if emoji only appear in casual speaker notes or decoration that won't project.