Pick a Template That Fits the Mood and Build an HTML Slide Deck
Use it when you need slides built from a content outline. It asks about the occasion and mood, shows three title-slide previews with your real content, then fills the chosen template without changing its look and checks every file in a browser.
To use this AI rule
## Ask About the Occasion and Mood Before Picking a Template
Ask two focused questions before reading or selecting templates.
First ask what occasion the presentation serves.
Examples include a founder pitch, research synthesis, brand manifesto, classroom kickoff, or design review.
Then ask what mood or vibe the audience should feel.
Examples include confident and punchy, quiet and literary, warm and playful, or dark and moody.
Wait for the user's answers before choosing a template.
Even a detailed brief does not remove this clarification gate.
Do not infer taste solely from the subject or industry.
Treat the user's emotional goal as primary design input.
Separate occasion from tone because one occasion can support several visual directions.
Ask about formality only when audience expectations make it relevant.
Ask about content density when the brief contains unusually much or little material.
Capture explicit light, dark, or mixed scheme preferences as hard constraints.
Do not start full production during this clarification gate.
Keep the questions brief enough that the user can answer immediately.
## Pick Three Clearly Different Templates That Fit the Mood
Read the template index before opening individual template files.
Match the answers against mood, tone, best-use description, and formality.
Use occasion as a soft signal rather than an industry whitelist.
Do not score templates by resemblance to the subject industry.
Use density to compare the template's demonstrated capacity with the content volume.
Use scheme as a hard signal when the user specified light or dark.
Treat avoid-use guidance as a soft warning.
Let an explicit user preference override a soft warning.
Choose exactly three candidates with genuine tonal fit.
Lead candidate descriptions with felt qualities rather than taxonomy.
Make the three candidates different enough to create a real choice.
Do not return three nearly identical editorial, corporate, or playful variants.
Include one direct fit, one credible alternative, and one thoughtful reinterpretation when possible.
Sanity-check formality against the audience.
Flag a serious mismatch such as a low-formality design for a conservative board.
Use demo slide count only as evidence of available layouts, not as a quality score.
Read full HTML and CSS only after a template reaches the shortlist.
## Make Title-Slide Previews With the Real Content
Inspect each shortlisted template's title slide and supporting visual system.
Extract only the first slide for preview.
Keep comparison inexpensive by limiting each preview to one slide.
Replace placeholder title, subtitle, author, and date with the user's real content.
Do not show generic placeholder copy in a selection preview.
Save each preview as a standalone HTML artifact in a temporary preview folder.
Use numbered filenames and stable descriptive slugs.
Keep every sibling stylesheet, script, font, and asset required by the preview.
Ensure each preview opens without relying on the original template folder.
Preserve the title slide's original dimensions and responsive behavior.
Use a consistent browser viewport when comparing candidates.
Do not redesign the preview before the user chooses.
Do not recolor, retype, or simplify the template's visual identity.
Verify that long real titles wrap without collision or clipping.
Check image placeholders, attribution, and date formatting.
Open every preview in a browser before presenting it.
Treat visual inspection as part of creation, not an optional follow-up.
## Show the Three Previews and Wait for the User's Choice
Open all three previews through the environment's browser-opening mechanism.
Send the user a numbered comparison.
Keep numbering and filenames stable so feedback maps to the correct candidate.
For each option, include the template name and a one-line tone description.
Provide the absolute path to each preview artifact.
Make paths directly usable or clickable in the current interface.
Describe why each candidate fits the requested feeling.
Do not replace the previews with a prose-only tradeoff discussion.
Ask which option feels right.
Wait for an explicit selection before building the full presentation.
Do not assume silence means approval.
If the user rejects all three, refine the mood interpretation and shortlist again.
Do not defend a candidate after the user's taste clearly rejects it.
Carry the chosen template forward as the single visual system.
Do not switch templates later because one slide is difficult.
## Put Real Content on Every Slide Without Changing the Template's Look
Clone the chosen template's complete folder into the user's project workspace.
Preserve fonts, weights, letter spacing, and line heights.
Preserve the full color palette and CSS variables.
Preserve layout grids, positioning systems, flex hierarchies, and spacing rhythm.
Preserve slide-level classes that carry the visual identity.
Preserve decorative elements such as grain, brackets, shapes, illustrations, and doodles.
Preserve the existing navigation runtime and interaction model.
Replace all headings, body text, list items, captions, statistics, names, dates, attributions, and authored tokens.
Treat section labels and chrome tokens as authored placeholders that also require replacement.
Replace every image placeholder with the user's image at the same dimensions.
Use heading, paragraph, list, and image elements appropriate to the real content.
Duplicate the closest existing layout when more slides are needed.
Remove unnecessary slides from the bottom when fewer are needed.
Update current-page and total-page labels after every slide-count change.
Adapt every slide; do not leave demo copy or placeholder numbers.
Keep the user's information hierarchy clear within the template's density limits.
Check every rewritten slide for overflow before proceeding.
## Design Missing Slide Types in the Same Style
Design a missing layout from scratch when the chosen template lacks a required slide type.
Do not return to the user merely because a comparison table or timeline is absent.
Do not import a layout from another template.
Use the same font families, weights, spacing, and typographic hierarchy.
Use only existing palette colors and choose the nearest accent when a new semantic color seems necessary.
Reuse the same decorative vocabulary and visual texture.
A bare undecorated slide inside an ornamental deck is a design failure.
Match slide padding, grid columns, gutters, and alignment rules.
Reuse the template's component grammar for cards, statistics, quotes, and captions.
Match top labels, page numbers, corner marks, and other chrome.
Insert the new slide as the same sibling element type used by existing slides.
Integrate it with the current keyboard, scroll-snap, or staged navigation behavior.
Test the new slide between two original slides.
If it looks grafted from another visual language, redesign it.
Proceed through implementation and verification without asking the user to solve the layout.
## Keep the Template's Fonts, Colors, and Layout Unchanged
Do not substitute a similar font when the original font fails to load.
Repair the import or asset path instead.
Do not recolor accents, backgrounds, or neutrals.
Do not combine slides from different templates.
Do not remove decoration merely because it appears nonfunctional.
Do not modernize an older visual style inside the chosen template.
Choose a different template during selection if the visual language is unsuitable.
Do not restructure grids to make content insertion easier.
Edit content length and hierarchy before breaking the layout.
Do not distort images to fill placeholders.
Crop or select assets that fit the intended aspect ratio.
Check every slide at the presentation's target viewport.
Inspect clipping, overflow, contrast, line wrapping, and navigation.
Verify page numbering and total counts after additions or removals.
Keep preview, iteration, and final files visually testable.
## Check Every File in a Browser and Share Its Path
Open every preview, intermediate iteration, and final presentation in a browser.
Do not announce an artifact before visually checking it.
Send the absolute path for each artifact.
Put each path on its own line when the interface supports clickable paths.
For the final presentation, name the chosen template generically and explain the tone match in one line.
Mention caveats only when they affect the delivered result.
Place any user-action caveat next to the final artifact path.
Identify slides designed from scratch when the original template lacked their layouts.
Keep the handoff concise: artifact, path, rationale, and material caveats.
Do not narrate the full production transcript.
Confirm that all required assets resolve from the delivered folder.
Confirm navigation works from the final file.
Confirm the final presentation contains no placeholder content.
Treat browser verification and path delivery as completion requirements.
Do not report completion if either requirement is missing.