choral-io Reveal.js Presentations
Create Reveal.js decks in the delivery mode requested by the user. General websites, PPTX editing, and speech outlines without deck implementation are outside this Skill. For review-only requests, inspect and report without editing or rebuilding the user's files.
Working example
When the user asks how to use this Skill or wants to see a finished example, open the interactive walkthrough in a browser. It is a self-contained English deck with offline playback and a speaker window opened with S or Speaker; allow the browser popup if needed. Read the HTML source only when inspecting or adapting the example. Its layout, language, pinned runtime, and custom speaker implementation are illustrative choices, not defaults for other decks.
Establish the delivery contract
Determine the audience, presentation duration, language, output location, and conditions below from the request and existing material. Reuse settled decisions; ask only about missing information that materially changes the result. Write the presentation in the user's requested language, independently of this Skill's language.
- Delivery mode: Choose a single file, static folder, or existing project using the table below. Source organization and delivery format may differ.
- Resource policy: Determine whether offline operation is required or CDN assets, remote media, and other network dependencies are allowed. An HTML presentation does not automatically require complete inlining.
- Launch method: Distinguish opening through
file://from serving over local HTTP. Establish requirements separately for the main deck and speaker view. One file does not guarantee every feature works when opened directly in every browser. - Feature scope: Determine whether the deck needs per-slide notes, current/next previews, fragments, mobile reading, printing, or PDF output. Add unspecified complex features only when their purpose justifies them.
Create or edit files only in authorized locations; preserve the personal status of personal drafts. Publish, commit, install globally, or upload assets only when the task authorizes those actions.
| Mode | Suitable requirements | Delivery contract |
|---|---|---|
| Single HTML file | One file for sharing, archiving, or offline transport | Embed all playback dependencies when offline operation is required; disclose network requirements when external resources are allowed |
| Static folder | Separate themes, scripts, images, or large media delivered as static resources | Deliver the entry HTML with its complete resource directory; verify relative paths and launch method |
| Existing project | An existing Reveal.js project, build toolchain, or ongoing maintenance workflow | Follow existing source and build entry points; deliver source and/or build output as requested, with preview instructions |
Use an explicitly requested mode. Prefer the established organization in existing projects. For a new deck without a specified mode, a static folder is a maintainable starting point; state that choice and adapt to requirements such as one-file sharing, strict offline operation, or deployment. Avoid introducing an application framework solely to make a deck.
Content and presentation
Establish a narrative appropriate to the available time, implement a few representative slides to validate layouts, then expand the deck. Give each slide one main conclusion supported by a suitable diagram, comparison, or sequence instead of pouring long-form prose into slides.
Keep conclusions and relationships on screen. Put background, terminology, examples, boundaries, and transitions in speaker notes. When notes are required, cover every actual content slide with relevant guidance; avoid repeated boilerplate or arbitrary truncation of terminology lists.
Choose visuals for the audience. Use real screenshots when available; label conceptual illustrations so they cannot be mistaken for implemented interfaces. Keep facts, assumptions, and proposals distinguishable, with traceable sources that do not crowd the narrative. Notes embedded in HTML are readable by recipients and are not secret storage.
Implementation and packaging
Prefer existing source, build entry points, and pinned dependencies. For a new deck, select an explicit Reveal.js version and verify its distribution and APIs; do not treat a historical version as the latest release. When choosing a delivery structure, packaging, or changing resource loading, read Delivery and packaging and apply the selected mode's guidance.
Preserve the .reveal > .slides structure and distinguish actual slides from vertical stack containers. Use layout variables for consistent canvas dimensions, margins, typography, and colors. Reduce content or split dense slides before shrinking text. Fragments should support the speaking sequence, and the final complete state must still fit.
For speaker views, dual previews, or synchronized controls, read Speaker view. Prefer an existing implementation that meets the launch contract; add custom behavior only when the standard plugin cannot meet an explicit requirement.
Validation and delivery
Follow Validation against the delivered entry point and resources, not only the development server. Rebuild after edits when a build step exists, then validate the fresh output.
Provide the artifact path, launch instructions, and necessary shortcuts. Briefly report the protocols, browsers, offline behavior, layouts, and speaker features actually checked. Separate failed or unperformed checks from passing ones; static scans do not replace browser validation. When a build workflow exists, preserve its reproducible entry point. Store test screenshots, logs, and temporary workspaces according to project rules, outside public Skill directories and unrelated deliverables.