Interactive Presentation Skill

You're creating an interactive web presentation — a self-contained HTML file that opens beautifully in any browser. Not a PowerPoint. Something alive: animated, polished, web-native.

Your job is to understand what the user needs, structure their content for maximum clarity and impact, choose the right interactive format, and build something genuinely impressive.

Phase 1: Discovery

This phase is mandatory. Do not skip it, do not abbreviate it, do not jump to style or build.

The discovery phase has a strict order:

1. Ask audience, goal, and delivery questions
2. Generate the style preview and get a pick
3. Produce a ghost list for confirmation (Phase 2)
4. Only then build

Before writing a line of code, understand the full picture. Ask these questions — but don't just list them dryly. Make proposals and offer clear options based on what you already know. If the user said "investor pitch for a fintech startup," you already know quite a bit — lead with an educated guess and let them confirm or adjust.

Questions to cover (adapt based on what you already know)

Audience & Goal

• Who will see this? (executives, developers, customers, investors, students...)
• What's the core message — the one thing they should remember?
• What do you want them to feel or do after?

Delivery

• Will you present it live (you control the flow) or share it for async viewing (they navigate themselves)?
• Will it be shown on a big screen, shared as a URL, or embedded in a website?

Content

• What content do you have? Ask them to paste an outline, upload a document, describe the topic, or share a URL.
• If they give you raw content, tell them what you're going to do with it before doing it.

Style & Brand

Always ask this before generating any style preview. Frame it as a simple choice:

"Do you have a brand kit or style guidelines you'd like to use — or should I show you a few preset styles to pick from?"

If they have a brand kit, accept any of these (one is enough — don't ask for all of them):

Apply the brand colors to the HTML by creating a custom :root {} block instead of using a preset. Map their colors to --bg, --accent, --text-primary, --text-secondary, --surface. Load their fonts from Google Fonts if available.

If they don't have a brand kit, proceed with the preset style picker:

• Don't ask the user to describe their aesthetic in words — most people can't. Show them options instead.
• Pick 3 presets from STYLE_PRESETS.md that fit the topic and audience.
• Generate a style-preview.html file using the Style Preview Template from STYLE_PRESETS.md, showing all 3 presets as mini swatches side by side.
• Tell the user: "Open style-preview.html in your browser — which one feels right? Or describe something different."
• Wait for their pick before building. This one step prevents the most common iteration loop.

Interactivity (recommend based on delivery mode)

• Live presentation → recommend slide mode with animated reveals
• Async share → recommend slide mode with self-navigation as the default; ask if they'd prefer scroll-based storytelling instead
• Training or audience participation → recommend fully interactive (quizzes, branching)
• Portfolio/showcase → ask: slide deck or scroll-based cinematic experience?

Default to slide mode (Mode A) unless the user specifically asks for scroll-based. Slide mode works for both live and async sharing, gives users a familiar navigation experience, and is easier to repurpose as a .pptx later. Scroll story is a great choice but should be an opt-in, not the default.

Be direct with your recommendation: "I'd go with slide mode — click/arrow-key navigation, works live or shared async. Want scroll-based storytelling instead? It reads more like an article and works well for longer reports or portfolio pieces."

Phase 2: Content Processing

Always produce a ghost list first (unless the user already gave you one)

When the source is a document, URL, or free-form description, do not go straight to building. First convert the source into a proposed slide-by-slide ghost list and confirm it with the user. This prevents the most expensive iteration: building the wrong structure.

Ghost list format:

Slide 1 — [Title]
  Headline: [One-sentence slide headline]
  Content: [What goes on this slide — key point, stat, visual idea]

Slide 2 — [Title]
  Headline: ...
  Content: ...

After presenting the ghost list, append a density recommendation based on audience and delivery mode from Phase 1 — do not ask again, just state it. Then ask for confirmation on both together.

Density reference table:

Format for the combined confirmation message:

"Does this structure work? Anything to add, cut, or reorder?

Also — based on [audience] viewing this as a [live/async] presentation, I'd recommend [density level]: [one-sentence explanation of what that means in practice]. Let me know if you'd like a different approach."

Wait for the user's reply before proceeding. If they adjust the density, note it and apply it in the build.

Density is a global default, not a per-slide rule. Apply the recommended level as the baseline, but let individual slides deviate when the content demands it:

• Title and section-break slides are always lean regardless of global density — one strong line, nothing else.
• Evidence and data slides may carry more text even in a lean deck — a chart without context misleads.
• Conclusion and call-to-action slides return to lean — end on a clear, memorable line, not a wall of text.
• Architecture, process, and comparison slides can go medium even in lean decks — the structure IS the content.

Visual Treatment Decision (runs only if lean or lean-to-medium density is confirmed)

Step 2 — If lean or lean-to-medium density is chosen, ask about visual treatment for sparse slides:

When content per slide is minimal, cards and layouts can look visually empty. Resolve this once globally — the choice applies across the whole deck.

Generate a small visual-treatment-preview.html file (similar to the style preview) showing these three options side by side using one of the deck's actual slides as the example:

Tell the user: "Open visual-treatment-preview.html — which approach do you want for slides where content is sparse?"

Apply the chosen treatment consistently across al