# Build Presentation > Collaboratively build a dark, interactive HTML slide presentation with text, images, diagrams, videos, and controllable animation. Use when the user wants a browser presentation developed and revised one slide at a time, with previous/next navigation and play/pause/stop controls. - Skill: `flpoliveira/build-presentation` (Agent Skill, multi-file: 12 files) - Install (CLI): `npx skillmds@latest add flpoliveira/build-presentation` - Raw SKILL.md: https://api.skillmd.com/api/skills/flpoliveira/build-presentation/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: flpoliveira (https://skillmd.com/u/flpoliveira) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/flpoliveira/build-presentation --- # Build Presentation Act as a presentation designer and implementation partner. Deliver an editable HTML experience the user can present locally. The default workflow is a conversation over successive working slides, not an entire deck produced in one pass. ## Collaborate one slide at a time 1. Read existing presentation files and `presentation-notes.md` before resuming work. Identify the active slide, accepted decisions, and unresolved requests. Preserve approved slides unless the user requests a change. 2. Establish subject, audience, desired takeaway, approximate speaking time, and language from context. Ask only for essential gaps in one compact question. Offer a short proposed arc if useful; an outline is a proposal, not permission to implement every slide. 3. Propose the current slide's message, content, composition, and meaningful interaction. If the brief gives enough direction, implement that first draft in the same turn. Otherwise wait for the missing content choice. 4. Build or revise **one slide per iteration by default**. Create the shared shell on the first iteration, but leave future slides in the notes as ideas. Explicit requests for several slides override the default for that batch. 5. Verify the changed slide, provide the working HTML path and a screenshot when available, explain what can be clicked or played, and ask one focused feedback question. End the turn so the user can respond. Do not run an autonomous approval loop or poll for feedback. 6. Apply feedback to that slide. Advance only when the user approves, says to continue, or redirects to another slide. A brief “looks good” accepts the current slide; it does not authorize completing the whole deck. Retain accepted slides when appending the next one. 7. Update `presentation-notes.md`: brief, outline, stable slide IDs, draft/approved status, current slide, accepted design choices, sources/assets, pending feedback, and next action. Record only approvals actually expressed. These are authoring notes, not audience-facing content. 8. Treat the presentation as finished only when the user says it is good and finished (or equivalent). Then rehearse the complete deck, resolve functional defects, and hand over the final HTML and required media. Do not add optional features after sign-off. Example when the brief is clear: “I’ll open with [message], using [visual]. Here is slide 1 in the working HTML. Does this establish the right context, or should the opening be more technical?” The next turn revises that opening or advances based on the answer. ## Reference and design Read [references/design-and-sources.md](references/design-and-sources.md) when beginning a deck or changing its visual language. It records the supplied *Transformer to LLM.html* reference and researched presentation patterns. Use its warm charcoal, ivory, terracotta/blue, generous space, editorial typography, diagrams, and restrained explanatory motion as defaults. Its subject is not the subject of every deck. Adapt composition to the message: a strong claim with an image, a comparison, a diagram, a timed explanation, or a video. Avoid repeating a title-and-three-bullets layout. Keep one main idea per slide and readable labels. Do not invent facts or quantitative examples without marking them illustrative. Source researched claims in notes or a discreet citation. Use supplied assets when available. Create precise diagrams with SVG/HTML; use raster generation when an illustration actually benefits. **Ask before downloading/installing packages, tools, browser binaries, fonts, plugins, or skills.** Do not auto-run package managers or use `npx` as an implicit installation shortcut. Prefer existing tools and native browser APIs; if verification tools are unavailable, report the limitation and provide manual checks. ## Build from the working starter ### When an animation is requested Read [references/motion-direction.md](references/motion-direction.md) before designing or revising an animated slide. It supplies the choreography workflow, timing ranges, camera rules, and visual acceptance rubric. For the concrete source analysis, read [references/neural-reference-study.md](references/neural-reference-study.md). Do not equate matching the palette with matching the animation quality. Propose the current slide's named teaching beats, persistent objects, causal actions, and reading holds. Build readable opening/key/final compositions, then animate their relationships. Preserve the slide-by-slide feedback loop and all approved navigation/transport behavior. Inspect multiple sampled frames and seek backward before calling the animation ready. Reuse [assets/motion.js](assets/motion.js) and the worked [scene markup](assets/motion-study.html) / [renderer](assets/motion-study.js) when useful. These are dependency-free examples, not mandatory neural-network content. `new_deck.py --motion-demo` builds a separate playable study showing object continuity, staged propagation, camera focus, chart growth, and a final held result. Use that mode for a demonstration only; normal authoring still starts with one draft slide. ### Scaffold and integrate Read [references/runtime.md](references/runtime.md) before implementing controls or animation. Start with the bundled dependency-free HTML unless the existing project provides a suitable framework: ```bash python3 /absolute/path/to/build-presentation/scripts/new_deck.py ./my-talk --title "My talk" ``` Resolve the script relative to this skill's actual location. It creates `index.html` with one draft slide plus `presentation-notes.md`; it refuses an existing output directory. Add `--demo` only for a separate three-slide controls demonstration. Demo copy is not the user's finished content. The starter includes inline CSS/JS/SVG, slide navigation, play/pause, stop/reset, scrubbing, incremental reveals, fullscreen, slide count, keyboard controls, and reduced-motion handling. It opens via `file://` without a server, install, or CDN. Adapt existing animations to the slide lifecycle instead of embedding an uncontrolled playback page. Default to one standalone HTML with embedded small assets. Use large videos as relative assets in a portable folder when inlining would be impractical; disclose required files. Do not promise a single file while referencing Downloads, absolute local paths, or remote URLs. GIF export is optional only when requested; it cannot replace the interactive HTML. ## Required presenter behavior - Next (button, Right Arrow, Page Down) reveals the next incremental item before advancing slides. Previous (button, Left Arrow, Page Up) hides items in reverse order before returning to the previous slide. Slides without incremental items navigate immediately. Changing slides stops outgoing playback; returning restores saved time and reveal state, paused. Keep first/last navigation enabled when there are still reveal steps to traverse. - Play/Pause preserves active animation/video time. Stop resets its timeline and reveals. Playback holds the final state; slide advancement is manual by default. - Scrubbing renders the selected moment. Static slides disable time controls honestly. - Show the bottom transport by default. Provide an always-accessible Hide/Show controls toggle outside it plus an H shortcut. Hide the navigation/playback bar and hint line together and refit the slide. Hiding must not reset or pause playback; keyboard navigation must continue working. Move focus out of hidden controls, label controls accessibly, and keep keyboard focus visible. Do not intercept keys inside native controls or editable content. - Hidden slides must not play audio, advance timers, animate independently, or receive keyboard focus. Tab hiding pauses playback. Reduced motion removes decorative transitions and supplies a readable still; intentional playback remains available. ## Verify and hand off each iteration Use available browser tools or an existing Playwright installation without installing anything. Check the HTML via `file://`: current slide, previous/next bounds, timeline freeze/resume/reset, return state, media leaving/reentry, and console errors. Inspect presentation-size and smaller-viewport screenshots for clipping or controls covering content. Check reduced motion when adding animation. Test media with the actual file; a placeholder does not prove playback works. Keep responses focused on the changed slide, a clickable preview path, any factual/media uncertainty, and the next feedback question. Preserve a usable deck throughout the conversation. For animation, use [scripts/capture_motion.mjs](scripts/capture_motion.mjs) with an existing Playwright installation to create a review sheet of teaching moments. Read its `--help`; it never installs dependencies. Inspect the generated screenshots, not just the command's exit status. If browser tools are unavailable, disclose that visual verification remains outstanding.