Azdmjiny/html-ppt-creator

HTML PPT Creator

Create a clear, visually intentional HTML slide deck that opens directly in a browser. Default to one self-contained presentation.html with inline CSS and JavaScript and no build step.

Workflow

1. Inspect the user's brief, source text, data, brand assets, and requested output location.
2. Infer reasonable defaults for missing details. Ask only when audience, purpose, language, slide count, or visual direction would materially change the result and cannot be inferred.
3. Design a concise slide sequence. Give each slide one job and a useful title; remove repetition before coding.
4. Choose a visual system that fits the subject. Define CSS custom properties for color, type, spacing, borders, shadows, and motion, then use them consistently.
5. Copy assets/starter.html as the base when starting from scratch. Replace all sample slides and theme tokens rather than treating the sample styling as a mandatory theme.
6. Implement the complete deck. Use semantic <section class="slide"> elements, a fixed 16:9 stage that scales to the viewport, and keyboard/click/touch navigation.
7. Read references/QUALITY.md before final QA. Open the deck in a browser when browser control is available, inspect every slide, fix overflow and interaction defects, then deliver the HTML file.

Do not introduce a planning checkpoint or require chapter-by-chapter approval unless the user requests an iterative workflow.

Output Contract

• Produce presentation.html by default. Use a multi-file folder only when the user requests it or the deck genuinely needs reusable local assets or substantial application logic.
• Keep the default deck offline-capable: inline CSS and JavaScript; use local or embedded images and fonts. Avoid CDN dependencies unless the user approves them.
• Preserve supplied facts, wording constraints, citations, logos, and brand rules. Never invent statistics or sources.
• Include a title slide, a coherent body, and a purposeful closing slide when appropriate; do not force these when the requested format says otherwise.
• Support ArrowLeft, ArrowRight, Space, PageUp, PageDown, Home, and End; support click/tap navigation and touch swipes. Use F for fullscreen.
• Show a subtle slide counter or progress indicator. Keep controls visually quiet and presentation-safe.
• Add print CSS so each slide prints as one landscape page and decorative controls are hidden.
• Respect prefers-reduced-motion. Use motion sparingly and never rely on animation to reveal essential information.
• Do not add speaker notes, narration scripts, audio, autoplay, recording helpers, video timelines, or TTS infrastructure unless explicitly requested.

Content and Visual Rules

• Make one main claim per slide. Prefer 3–6 concise supporting items over paragraphs.
• Use the right visual form for the relationship: comparison, process, timeline, hierarchy, metric, quote, image, chart, or diagram.
• Prefer real content, simple SVG, CSS diagrams, and meaningful charts over decorative filler.
• Maintain strong hierarchy and generous whitespace. Design for viewing at a distance, not document reading.
• Keep a coherent theme across the deck while allowing layout variety. Avoid making every slide the same grid of rounded cards.
• Avoid generic AI styling: gratuitous purple gradients, excessive glow, random glass panels, emoji decoration, fake app chrome, and ornamental charts without data.
• Ensure text contrast, visible focus states, useful alt text, and a sensible DOM reading order.
• If content does not fit, shorten it or split the slide. Do not shrink body text until it technically fits.

Editing Existing Decks

Preserve the current architecture and design language unless the user asks for a redesign. Make the smallest coherent change, then recheck navigation, slide numbering, overflow, print layout, and responsive scaling.

Completion Check

Before reporting completion:

1. Verify the requested messages, numbers, citations, and slide order.
2. Test first/last-slide boundaries and every navigation method.
3. Inspect all slides at 16:9 desktop size and at least one smaller viewport.
4. Check for clipped text, collisions, tiny type, broken media, console errors, and accidental scrolling.
5. Confirm the file opens without a build step and remains usable offline unless external dependencies were approved.
6. Fix every failure before handing off the result.