create-slides

Create Slides

Critical rules

• No libraries, CDNs, frameworks, or build steps in the deck itself. It must open directly from a local index.html.
• Never rebuild core/slides.js. Navigation, key handling and the data-enter/data-exit contract are fixed. Extend by layering on SlidesRuntime.controller, the way core/morph.js does.
• Never edit core/slides.css per deck. It owns structure, archetype layout and the reveal presets. Override in theme.css, or in deck.css.
• Fonts must be inlined as data URIs (tools/fonts.mjs). @font-face files are blocked over file://, so a deck opened by double-click loses them.
• Never invent facts, statistics, quotes, images, or licenses. Research current claims with the web-research skill, cite sources, and record where every asset came from.
• Derive tokens and content from the subject; derive the look from a template. Do not invent a new layout system mid-pass.
• Write semantic HTML: real headings, lists, figures, one <section class="slide"> per slide in DOM order.
• "Use the space" ≠ stretching boxes to fill the viewport. It means stable hierarchy, content-sized modules, comfortable gaps, and intentional margin.
• Verify before reporting done. npm run qa for the deck, npm run audit after any recording. Never call a deck or an export finished on the strength of having looked at it.
• User-owned copy is sacred. After the user edits text, change layout and CSS only — never rewrite their wording unless asked.
• State every assumption explicitly in the final report.

Workflow

1. Inspect everything supplied — content, data, brand, delivery mode, and any script or captions the deck must back.
2. Ask one grouped question covering only the real gaps. Always include the look unless the user named a template or gave brand direction that settles it. Defaults in brackets if you must proceed on assumptions:
   • Look: dark-marker (courses, tutorials) | light-editorial (talks, reports) | midnight-tech (developer content) | bold-keynote (pitches) | minimal-mono (research talks) — one line each, and say which you'd pick
   • Delivery: live talk | recorded video/tutorial | self-paced send
   • Reveal model: multi-step | one-step staggered | none
   • Density: sparse keynote | tutorial-comfortable
3. Research unknown or current facts before writing any slide body.
4. Read references/design.md. Outline the deck as titles only and check that sequence carries the message before writing any body copy.
5. Scaffold the deck:
   • assets/core/ → core/, assets/skeleton.html → index.html
   • the chosen assets/templates/<name>/ → theme.css, fonts.json
   • assets/tools/ → tools/, assets/starter/* → deck root (gitignore → .gitignore)
   • create an empty deck.css
   • npm install && node tools/fonts.mjs
   • npm run dev renders every archetype the template offers — read it before writing slides.
6. Adapt tokens only to the subject, then write the slides. Read references/web-slides.md for the DOM, composition and archetype contract, and references/motion.md before setting any reveal or preset.
7. Verify: npm run qa, and fix everything it reports.
8. Export if asked — references/export.md: npm run pdf, npm run record / record:2k / record:4k, then npm run audit. When the deck backs a recorded voiceover, time the reveals from the caption file: a sidecar timings/<video>.json per video, validated with node tools/record.mjs --timing <file> --plan. Timings never go in the markup — the deck only gains a data-slide handle per timed slide.
9. Report the files, how to open them, the controls, the template used, every assumption, and sources for any researched claim or asset.