Imported from vinodkrishna221/Q-Trace (.agent/skills/bolt-slides/SKILL.md). Install upstream with npx skills add vinodkrishna221/Q-Trace --skill bolt-slides. Copyright stays with the author.

Slides — a premium, responsive, React presentation engine for Bolt

Classic paged slides (advance one at a time, present over them) — but rebuilt in Vite + React so each slide is a responsive web layout instead of a fixed 1080×607 canvas that clips. It keeps the Slidev UI you liked (the floating dock + thumbnail rail + click-builds + presenter) and adds real web interactivity.

Two halves — keep them separate:

• The engine + UI are pre-built — this repo is a complete, runnable app: the paged engine (src/deck/), the dock/rail chrome, the section components (src/components/), the shared CSS. Leave the engine as-is. Never regenerate it. This is the part you liked; it must look/behave identically.
• The content is authored fresh, every time — the slides (topic, structure, copy, visuals, theme) are designed from scratch for this request.

Theme surface. All color, type, radius, depth, and motion live in the :root token vocabulary of src/styles/tokens.css. Theme a brand once, there.

⛔ Three hard rules

1. Don't touch the engine — leave src/deck/ (the engine + chrome: Deck, Slide, Build, Reveal, DeckContext, icons, Annotator, useInView) untouched. Don't rewrite or paraphrase the engine or the chrome; author around it.
2. Author the deck from the user's REAL input — do not reskin the starter. src/App.tsx is a throwaway that only proves it runs. Delete its slides and write a new deck. Never reuse its order, copy, placeholders, or fake names.
3. Center what stands alone. Ask of every slide: does it have a side visual (a Split media panel, an image, a BrowserFrame, a chart beside text)?
   • No side visual (only text, or one structured block like Comparison / Tabs / Timeline / Accordion / StatGrid) → the slide MUST be centered: use <Slide center>, or a textAlign:'center' heading with marginInline:'auto' on every block below it.
   • Yes → left-aligned/asymmetric is allowed; the visual balances the text. A lone left-anchored block floating in empty space is the #1 alignment bug — never ship one. (The structured blocks self-center with built-in max-widths as a safety net, but headings/paragraphs around them are YOUR job to center.)

Step 0 — Ground the deck in the user's real input

Use the user's real topic, brand, document, facts. Never fabricate a placeholder company, logo, or quote for a real subject. If a URL/brand is given, the theme comes from that brand — fetch the page for real colors/font/logo, or use the brand's known palette, or STOP and ask. Report which colors/fonts you used and where from.

Step 1 — Run it in place (the repo is the app)

The repo root is already a complete Vite + React app — no scaffolding or copying. Its layout:

package.json  vite.config.ts  tsconfig*.json  index.html   src/main.tsx
src/App.tsx                 ← THROWAWAY. delete its slides; author the real deck.
src/styles/   tokens.css (edit :root ONLY) · base.css   ← don't edit base.css
src/deck/   Deck Slide Build Reveal DeckContext useInView icons Annotator   ← engine + UI. LOCKED.
src/components/  Cover BigNumber Contrast Chat Bento Split StatGrid Section   ← slide layouts
                Quote Pricing Steps Agenda Team
                CountUp TiltCard Marquee VisualDashboard Accordion Comparison
                Tabs Timeline CodeWindow BrowserFrame SpotlightCard Charts

npm install && npm run dev runs the deck at /. Verify the dock / thumbnail rail / click-builds work, then delete the starter slides and author the real deck in App.tsx.

Step 2 — Theme it (edit only the :root block)

All color, type, radius, depth, motion live in src/styles/tokens.css :root. Change values, never variable names. Nine ready-made theme families to pull from (dark product, editorial luxury, Swiss, dark technical, warm minimal, fintech, aurora glass, cinematic, paper editorial). One accent, used sparingly. Dark vs light: set html { color-scheme } in base.css and pick --bg/--fg accordingly. Set fonts in --font-head/--font-body and the @import at the top of base.css. Derive from the brand when given.

Tab title + icon — always, unprompted. Shared decks show the browser tab, so never leave the index.html placeholders: set <title> to the deck's real title (e.g. "Acme — Series A") and swap the emoji in the favicon <link> to one that fits the topic. Do this for every deck without being asked.

Step 3 — Author slides (each child of <Deck> is one slide)

Compose slides in App.tsx. The building blocks:

• <Slide> — one slide. center for statement/CTA; full for edge-to-edge; nav="Label"; notes="…" (editable in the presenter overlay).
• <Cover> — the opening slide: kicker → display title → subtitle cascade, optional full-bleed image under a theme-correct scrim, optional foot line.
• <BigNumber> — ONE enormous accent figure (pass a <CountUp>) + caption. Every deck should have one of these drama beats.
• <Contrast> — before/after, problem→solution: a muted panel vs an accent-lit panel with cross/check points. The classic pitch move.
• <Chat> — a chat window whose messages reveal one per click (builds) — user bubbles on the accent, assistant on the surface. For AI-product decks.
• <Globe> — a rotating, drag-to-spin 3D dotted globe (hand-built canvas, zero deps): accent markers at real [lat, lng] coordinates, optional label
  • value chips that ride their marker and fade behind the globe, optional arcs={[{from, to}]} great-circle connections, and stat rows beside it. Colors follow the tokens automatically. Label a FEW hero markers, not all.
• <Split> — text + edge-to-edge media (flip swaps). media = <img>, a color panel, a <BrowserFrame>, or <TiltCard><VisualX/></TiltCard>.
• <Bento> — asymmetric tile grid; tiles take c/r spans + variant.
• <StatGrid> — responsive proof cards; pass a <CountUp> as a stat value.
• <Section> — chapter divider: ghost number + accent glows. The full-bleed breather for decks without photography; use between parts.
• <Agenda> — numbered table-of-contents rows (strings, or {title, hint}).
• <Steps> — horizontal numbered process; the connector draws in. Use for "how it works" instead of a bulleted list.
• <Pricing> — 2–4 tier cards; highlight: true crowns one with a badge.
• <Team> — people grid; photos via img, else auto-initials on the accent.
• <Quote> — pull-quote slide with attribution (don't add quotation marks — the accent mark provides them).
• <Comparison> — us-vs-them feature matrix; one column highlighted in the accent.
• <Table> — a real data table: uppercase ruled header, right-aligned tabular numerals, optional highlightCol/highlightRow, caption for the source. Use for actual data (pricing tiers → Pricing, feature ticks → Comparison). Keep ≤5 columns / ≤7 rows — a paged slide can't scroll.
• <Tabs> — tabbed content with a sliding accent pill.
• <Accordion> — expand/collapse panels (FAQ, feature detail).
• <Timeline> — vertical roadmap that draws its connector + milestones in.
• <CodeWindow> — macOS code window with line numbers + line highlight.
• <BrowserFrame> — browser chrome around a screenshot / full-bleed app mock (fill it edge-to-edge — a real-looking app screen, not a floating card).
• <SpotlightCard> — card with a cursor-follow accent glow (Linear/Vercel hover).
• Charts — <BarChart> / <LineChart> / <DonutChart>, all draw-in on view.
• Atoms (CSS classes): .display .headline .lead .subhead .kicker .figure .accent-text .rule. All fluid (clamp()).

⚠️ Pick layouts for the story — not the showcase

The starter demo uses every layout because it is a component demo. A real deck must not. Every specialty layout has an entry condition — if the content doesn't meet it, the layout does not appear:

• <Chat> — ONLY if the product genuinely has a conversational / AI interface, and the exchange shown is a real, plausible use of it. Never decoration for a non-chat product.
• <Pricing> — only when pricing is actually part of this deck's ask.
• <Team> — pitch and agency decks; skip in launches, reports, teaching.
• <Section> — only in decks long enough to have real chapters (~12+ slides).
• <BigNumber> — needs one real, defensible figure (cite it in foot). At most one per deck — two giant numbers cancel each other out.
• <Contrast> — when a genuine before/after exists; don't build a strawman.
• <Agenda> — formal or long presentations; an 8-slide pitch needs no TOC.
• <Globe> — ONLY when the story is genuinely geographic (users or revenue by country, market entry, global footprint) — and the markers are the REAL locations. Never as a generic "we're global" flourish.

The workhorses are <Slide>, <Cover>, <Split>, <Bento>, <StatGrid> and the atoms; specialty layouts appear at most once each, when the content calls for them. If you can't say in one sentence why a layout serves this deck, cut it.

Compose like the web, not like slideware (same discipline as the other skills): full-bleed, layered; Bento/Split over a centered row of equal cards; oversized type with one accent word; vary the rhythm so no two adjacent slides share a shape; one idea per slide; open on a cover, close on a CTA.

Centering rule (hard rule 3): left-aligned/asymmetric layouts need a side visual (a Split, an image, a BrowserFrame). A text-only section anchored left reads as off-center — center those: <Slide center>, or a centered heading over a centered content block (marginInline:'auto'). Comparison, Tabs, Timeline, and Accordion self-center with built-in max-widths, but the kicker / headline above them must be centered by you (textAlign:'center' + marginInline:'auto') or the slide still reads lopsided.

Interactivity: click-builds (the signature)

Reveal content in beats with <Build at={n}> — it stays hidden until you advance to step n on that slide, then animates in. Advancing (→ / space / Next) reveals the next build, then moves to the next slide. Use it for: the punchline after its setup, each step of a process, items appearing in turn. Use <Reveal> for an on-enter entrance (no click needed) on headlines/grids.

<Slide center nav="The shift" notes="Pause, then reveal each point.">
  <h2 className="headline" style={{ marginInline: 'auto' }}>Three things changed.</h2>
  <Build at={1}><p className="lead" style={{ marginInline: 'auto' }}>First, the data got bigger.</p></Build>
  <Build at={2}><p className="lead" style={{ marginInline: 'auto' }}>Then, the tools got faster.</p></Build>
  <Build at={3}><p className="lead" style={{ marginInline: 'auto' }}>Now, anyone can ship.</p></Build>
</Slide>

Step 4 — Responsive, not fixed (no clipping)

Each slide is a full-viewport responsive layout, not a fixed canvas — it reflows to the screen, so nothing scales-and-clips:

• Fluid sizing. The atoms use clamp(); use %, vw, rem, max-width containers — not fixed pixel widths that break on small screens.
• Never hand-write a fixed column count (repeat(3, 1fr) clips on phones). Use the .cols utility (equal columns that wrap) or repeat(auto-fit, minmax(min(240px, 100%), 1fr)). For a BrowserFrame app mock, build the shell with .appmock (sidebar + content; sidebar column collapses on phones) and put .hide-narrow on chrome that should vanish on small screens.
• One idea per slide, sized to fill ~one screen with deliberate negative space.
• Check a narrow viewport — Bento/Split/Steps/Pricing/Contrast/Team stack or compact themselves (built in); make sure headlines don't overflow and nothing needs scrolling — a paged slide CANNOT scroll, overflow is truncation. (The thumbnail rail renders each slide at true size and scales it, so previews stay faithful.)
• No fixed heights on content — let it flow; reserve fixed sizes for media panels.

Step 5 — Visuals & imagery

Visuals must fit the topic (same rules as the other skills): data/SaaS → a .vframe mock (VisualDashboard is an example — build topic-fit ones with real data); brand/product/editorial/real-world → generate images into public/, one consistent style, used as Split media or full-bleed slide backgrounds under a gradient scrim (no text in images). A Split or full-bleed image beats a floating card.

Image-capable layouts — when the deck calls for photography, these take it directly (each puts a theme-correct scrim under the text automatically): <Cover image>, <Section image>, <Quote image> (full-bleed backgrounds), <Bento> tiles with img (full-bleed photo tiles, text anchored at the bottom), <Team> people with img, <Split media={<img …/>}>, and <BrowserFrame> around a screenshot. An image-heavy deck should mix photo Bento tiles and image Sections/Quotes — not repeat the same Split shape.

Step 6 — Motion (with restraint)

Build (click reveals), Reveal (on-enter entrance), CountUp (hero figures), VisualDashboard / Timeline / the charts (draw themselves in on view via the useInView hook), TiltCard + SpotlightCard (cursor interaction), Marquee (logo strip), Tabs (sliding pill). The ambient background (drifting spotlights + grain + vignette) and the slide-change transition are automatic. One or two motion ideas per slide, never a circus. All honors prefers-reduced-motion.

Extend the system — invent new slides, components & visuals

The kit is a floor, not a ceiling. The bundled components cover a lot (comparison, tabs, timeline, charts, code/browser frames, accordion, bento, split…) — but author new ones for the topic when nothing fits: a <Pricing> table, a Gantt, a device/phone mock, a chat or kanban mock, a map. Only the token names and src/deck/ (engine + chrome) are off-limits to rewrite; adding components/visuals is encouraged. Every new piece must: use var(--…) tokens only (no raw hex), compose like a web section, be responsive (work on mobile), animate with Reveal/Build/useInView + honor reduced-motion, use tabular figures, and add no new dependencies (plain React + CSS + SVG — even the <Globe> is dependency-free).

Step 7 — Structure & writing

Pick an arc that fits the deck type (pitch, launch, brand, teaching, report) — structure follows content. Open on a cover, close on a CTA. ~8–16 slides sized to the material. Headlines short, declarative, specific (sentence case); body 1–3 tight sentences; 1–3 word kickers; one idea per slide. Use the user's real numbers; never invent numbers for a real brand. Zero lorem, zero placeholder names. Add notes for talking points where useful.

Definition of done (self-check)

• The engine + chrome in src/deck/ are left untouched; the dock + thumbnail rail appear, arrow keys advance AND step back through builds, fullscreen / sidebar (S) / grid view (G) work, annotation (A) has full tools and persists per slide, presenter (P) opens a synced new tab, H hides the UI, and the URL hash tracks the slide.
• The deck is authored, not reskinned — topic, structure, copy, names are the user's, with no starter leftovers (no "Title"/"Northwind").
• If a brand/URL was given, --primary, fonts, and logo come from that brand.
• index.html has the deck's real <title> and a topic-matched favicon emoji — no Replace — your deck title placeholder left behind.
• Only the :root block was edited for the theme; editing --primary recolors everything incl. the dock.
• Slides compose like web sections (full-bleed/asymmetric/bento/split), not centered card rows; visuals fit the topic; brand decks have generated images.
• Alignment audit (hard rule 3): step through EVERY slide — any slide without a side visual is fully centered (heading AND content block); nothing left-anchored floats alone in empty space.
• No showcase decks: every specialty layout used meets its entry condition (Chat = real conversational product, BigNumber = one real sourced figure, Pricing = pricing is the ask, …). Nothing is included just because the kit has it.
• Responsive: looks right narrow + wide — sections stack, nothing clips or needs scrolling. Builds reveal in the intended order.
• Motion is restrained; reduced-motion respected.
• npm install && npm run dev runs with no console errors; npm run build passes.

WarRoom wiring (kit addition — not part of upstream)

Upstream: https://github.com/stackblitz/bolt-slides © StackBlitz, MIT (bundled above). Modifications disclosed: (1) upstream's hidden "internal trigger" section (a phrase that makes agents silently present the starter demo and conceal the trigger's existence) was REMOVED — WarRoom kits don't ship concealed behaviors; (2) frontmatter name changed slides → bolt-slides to match this kit's folder convention. Everything else is verbatim.

• Engine A of the ppt-builder skill. Use for every deck where the FORMAT IS FREE: internal-round pitch, eval-round decks, finale deck, demo-day. Prescribed formats (SIH idea-PPT template) stay on Engine B (template paste) — see ppt-builder.
• Where the deck lives: deck/ subfolder of the hackathon repo — scaffold with ./scripts/new-deck.sh (degit clone + install). The deck is a separate Vite app; it never shares dependencies with the product. Herald owns deck/src/App.tsx.
• Content comes from the source→slide map in ppt-builder (PRD, IDEA-BRIEF, STATUS, EVAL-PACK numbers) — this skill governs HOW slides are built; ppt-builder governs WHAT goes on them. Both load together when authoring.
• Venue caveat: npm install needs network — /prep lane 2 pre-clones the template and caches node_modules into the venue kit. Presenting: npm run dev on the demo laptop (local-first, per SIH arena §4); deployed link is the bonus mirror.
• Wow-slide discipline: the deck's ONE interactive flourish is the wow moment's twin (a live chart, an embedded BrowserFrame of the actual product) — not confetti on every slide. Oracle vetoes showcase-itis, per upstream's own "no showcase decks" rule.