@open-aippt/core 1.13.2

package/package.json

@@ -0,0 +1,103 @@
+{
+  "name": "@open-aippt/core",
+  "version": "1.13.2",
+  "description": "Runtime and CLI for open-aippt — write slides in slides/, we handle the rest.",
+  "type": "module",
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "import": "./dist/index.js"
+    },
+    "./vite": {
+      "types": "./dist/vite/index.d.ts",
+      "import": "./dist/vite/index.js"
+    },
+    "./locale": {
+      "types": "./dist/locale/index.d.ts",
+      "import": "./dist/locale/index.js"
+    },
+    "./env": {
+      "types": "./env.d.ts"
+    }
+  },
+  "bin": {
+    "open-aippt": "./bin.js"
+  },
+  "files": [
+    "bin.js",
+    "dist",
+    "env.d.ts",
+    "src/app",
+    "src/locale",
+    "skills",
+    "README.md"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "keywords": [
+    "slides",
+    "presentation",
+    "react",
+    "vite"
+  ],
+  "license": "MIT",
+  "author": {
+    "name": "aibabelx",
+    "url": "https://github.com/aibabelx"
+  },
+  "homepage": "https://open-aippt.dev",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/aibabelx/open-aippt.git",
+    "directory": "packages/core"
+  },
+  "bugs": {
+    "url": "https://github.com/aibabelx/open-aippt/issues"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "dependencies": {
+    "@babel/parser": "^7.29.2",
+    "@babel/types": "^7.29.0",
+    "@dnd-kit/core": "^6.3.1",
+    "@dnd-kit/sortable": "^10.0.0",
+    "@dnd-kit/utilities": "^3.2.2",
+    "@fontsource-variable/geist": "^5.2.8",
+    "@tailwindcss/vite": "^4.2.2",
+    "@vitejs/plugin-react": "^4.3.3",
+    "chalk": "^5.3.0",
+    "class-variance-authority": "^0.7.1",
+    "clsx": "^2.1.1",
+    "commander": "^15.0.0",
+    "emoji-picker-react": "^4.19.1",
+    "fast-glob": "^3.3.2",
+    "fflate": "^0.8.2",
+    "html-to-image": "^1.11.13",
+    "lucide-react": "^1.8.0",
+    "next-themes": "^0.4.6",
+    "radix-ui": "^1.4.3",
+    "react": "^18.3.1",
+    "react-dom": "^18.3.1",
+    "react-image-crop": "^11.0.10",
+    "react-router-dom": "^7.18.0",
+    "shadcn": "^4.11.0",
+    "sonner": "^2.0.7",
+    "tailwind-merge": "^3.5.0",
+    "tailwindcss": "^4.2.2",
+    "tw-animate-css": "^1.4.0",
+    "vite": "^5.4.10"
+  },
+  "devDependencies": {
+    "@types/node": "^22.19.17",
+    "@types/react": "^18.3.12",
+    "@types/react-dom": "^18.3.1",
+    "tsdown": "^0.9.9",
+    "typescript": "^5.9.3"
+  },
+  "scripts": {
+    "build": "tsdown",
+    "typecheck": "tsc --noEmit"
+  }
+}

package/skills/apply-comments/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: apply-comments
+description: Apply pending @slide-comment markers written by the open-aippt inspector tool. Use when the user asks to "apply comments", "process slide comments", "apply the inspector comments", or references markers left inside `slides/<id>/index.tsx`.
+---
+
+# Apply slide comments
+
+The open-aippt editor has an inspector tool that lets the user click on a rendered page element and attach a textual comment (e.g. *"make this red"*, *"change to 'open-aippt Rocks'"*). Each comment is persisted as an in-source JSX marker inside `slides/<slideId>/index.tsx`.
+
+Your job: read those markers, perform the described edits, and delete the markers.
+
+> **Before making any page edit**, consult the **`slide-authoring`** skill — it is the technical reference for how `slides/<id>/index.tsx` is structured (canvas, type scale, palette, assets, file contract). A comment like *"make this bigger"* or *"change the accent colour"* should be applied in a way that stays consistent with those rules.
+
+## Marker format
+
+```
+{/* @slide-comment id="c-<8hex>" ts="<ISO>" text="<base64url(JSON)>" */}
+```
+
+- Always sits on its own line as the **first child inside** the JSX element it refers to (i.e. between that element's opening `>` and its other children). The marker is dropped *into* its target, not floated above it.
+- `text` is base64url-encoded JSON: `{"note": "...", "hint"?: "..."}`.
+- Detection regex (authoritative — use exactly this):
+
+  ```
+  /\{\/\*\s*@slide-comment\s+id="(c-[a-f0-9]+)"\s+ts="([^"]+)"\s+text="([A-Za-z0-9_\-]+={0,2})"\s*\*\/\}/g
+  ```
+
+## Procedure
+
+1. **Identify the target slide(s).**
+   - If the user names one (`example-slide`, `youbike-3-survey`, etc.), work on that single `slides/<slideId>/index.tsx`.
+   - If they say "all" or don't specify, scan every `slides/*/index.tsx`. Process each slide one at a time.
+
+2. **Read the file and find all markers.**
+   - Run the regex above against the whole file.
+   - For each match, base64url-decode `text` and `JSON.parse` it to get `{ note, hint? }`.
+   - Record each hit as `{ id, lineIndex (0-based), indent, note, hint }`.
+   - If there are no markers, tell the user and stop.
+
+3. **Understand each comment in context.**
+   - The targeted JSX element is the **enclosing** element of the marker — i.e. read upward from the marker line until you reach the unclosed JSX opening tag whose body the marker lives in. That element is the target. (For self-closing elements like `<img />`, the inspector hoists the marker to the nearest non-self-closing ancestor; in that case the comment usually refers to a child of the enclosing element rather than the enclosing element itself — use the `note` text to disambiguate.)
+   - Read enough surrounding code (parent element, sibling elements, inline styles) to apply the change faithfully. A comment inside a `<div>` with an inline `background` style usually refers to that element's styling, for example.
+   - If the `note` is ambiguous, do the smallest reasonable interpretation and mention the assumption in your summary.
+
+4. **Apply edits in reverse line order.**
+   - Sort markers by descending `lineIndex` and process one at a time, using the `Edit` tool.
+   - Processing top-down would invalidate line numbers for later markers as the file shrinks/grows.
+
+5. **Remove each marker after applying its edit.**
+   - Delete the entire marker line including its trailing `\n`.
+   - Never leave a marker behind. An un-removed marker signals a failure.
+
+6. **Verify.**
+   - After all edits, re-read the file and confirm zero remaining markers.
+   - Run `pnpm tsc --noEmit` and `pnpm biome check` (or `pnpm lint`). Fix any introduced errors.
+
+7. **Report.**
+   - Summarise: `N applied, 0 remaining` plus a one-line description of each change (including the slide id).
+
+## base64url decoding helper
+
+```js
+function decode(s) {
+  const pad = s.length % 4 === 0 ? '' : '='.repeat(4 - (s.length % 4));
+  return Buffer.from(s.replace(/-/g, '+').replace(/_/g, '/') + pad, 'base64').toString('utf8');
+}
+```
+
+You can run this inline via `node -e '...'` if you need to inspect a payload; otherwise just reason about the decoded string.
+
+## Edge cases
+
+- **Marker with no enclosing JSX element** (shouldn't happen — the inspector won't write one — but if you find one): delete it and note as orphan.
+- **Multiple markers stacked on consecutive lines inside the same element**: they all refer to that enclosing element. Apply them in source order but still delete each line individually.
+- **`_debugSource` used SWC instead of Babel**: not your problem — the marker line is authoritative.
+- **Comment asks for something outside the target element's scope** (e.g. "add a new page"): do the closest-reasonable edit and mention the scope expansion in your summary.
+- **Can't resolve the comment** (e.g. truly ambiguous, or the file changed shape such that the target element doesn't exist): leave the marker in place and report it as skipped. Don't guess.
+
+## Do not
+
+- Do not touch `package.json`, `open-aippt.config.ts`, or files outside `slides/`.
+- Do not add dependencies.
+- Do not re-introduce markers or leave `TODO` breadcrumbs — the user already has a record in git.

package/skills/create-slide/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: create-slide
+description: Use this skill when the user wants to create, draft, author, or generate new slides / a presentation in this open-aippt repo. Triggers on phrases like "make slides about X", "create a presentation", "draft slides for", "new slide", or when the user asks to add content under `slides/`. Do NOT use for editing the framework itself — only for authoring content inside `slides/<id>/`.
+---
+
+# Create a slide in open-aippt
+
+This skill owns the **workflow** for drafting a new deck. The technical reference — file contract, 1920×1080 canvas, type scale, palette, layout, assets — lives in the **`slide-authoring`** skill. Read that skill whenever you need details on *how* a page is structured. This skill assumes you'll consult it before writing code.
+
+You only write files under `slides/<id>/`. Never modify `package.json`, `open-aippt.config.ts`, or existing slides.
+
+## Step 1 — Pick a theme
+
+List files under `themes/`. If any theme markdown files exist (anything other than `README.md`), call `AskUserQuestion` with each theme id as an option plus a final **"no theme — design from scratch"** option.
+
+- If the user picks a theme: read `themes/<id>.md` end-to-end. The theme's palette, typography, layout, and Title/Footer components are now authoritative — copy them directly into the slide. **Also set `theme: '<theme-id>'` on the `meta` export in `index.tsx`** (e.g. `export const meta: SlideMeta = { title: '…', theme: '<theme-id>' };`) so the slide back-links to the theme (chip on the slide card + listing on `/themes/<id>`). In Step 2, skip the **aesthetic direction** question (the theme already commits to one direction); you still need the topic itself, so confirm it before moving on. Page count, text density, and motion are independent of theme — ask those normally.
+- If the user picks "no theme", or `themes/` is empty (or contains only `README.md`): proceed to Step 2 unchanged.
+
+If you skip the aesthetic question because a theme was picked, restate the theme name in Step 2 so the user can correct course before you start writing.
+
+## Step 2 — Clarify requirements (MUST ask before writing code)
+
+**Before writing any code, lock in the four key style decisions below via `AskUserQuestion`.** They shape every downstream choice (layout, type scale, asset needs, motion code), so locking them in up front avoids rework. Only skip a question when the user's original message already gave an unambiguous answer for it — and if you skip, restate your assumption so they can correct it.
+
+**Topic comes first.** A meaningful aesthetic recommendation requires knowing what the deck is about. If the user's initial request is thin ("make me a deck", "draft some slides"), make a *separate* `AskUserQuestion` call first to gather topic, audience, and any draft outline. Skip this only if the topic is already clear from the user's message — in which case restate your reading of the topic in the next call so they can correct course.
+
+Then ask these four in a single `AskUserQuestion` call (multi-question form):
+
+1. **Aesthetic direction** — propose 3 visual directions tailored to *this* topic. Do **not** pull from a fixed preset list. Each option must combine a vibe word + a concrete visual cue (palette, typography, motif) so the user can picture it; bare labels like "minimal" or "corporate" alone are too vague. The three options should feel meaningfully different from each other — not three flavors of the same idea.
+
+   How options should shift with topic:
+   - *"Intro to Rust for backend engineers"* → **rust-orange technical editorial** (warm rust/charcoal, mono headings, code-grid layout) · **blueprint dev-doc** (cyan grid on near-black, monospace, schematic feel) · **brutalist terminal** (lime-on-black, ASCII rules, no-nonsense)
+   - *"Q2 product roadmap for stakeholders"* → **calm corporate clean** (off-white, single accent, generous whitespace) · **confident editorial** (large display serif, tight grid, one bold accent) · **data-forward dashboard** (charts as hero, muted neutrals + status colors)
+   - *"Kindergarten parent night"* → **playful crayon** (paper texture, hand-drawn accents, primary colors) · **soft pastel storybook** (peach/mint, rounded type, illustrated icons) · **warm photo-led** (full-bleed kid photos, simple captions)
+
+   Mark the option that best fits the topic and audience as "(Recommended)" so the user has a sensible default. (`AskUserQuestion` already auto-adds "Other" — don't add a generic catch-all yourself.)
+
+2. **Page count** — rough length. Offer brackets: 3–5 (short), 6–10 (standard), 11–20 (deep dive), custom.
+3. **Text density per page** — how much copy lives on each page? Offer: minimal (one line / big number), light (heading + 2–3 bullets), standard (heading + 4–5 bullets or short paragraph), dense (multi-column / detailed). This directly drives type scale and layout.
+4. **Motion** — does the user want CSS/React animations and transitions, or a fully static deck? Offer: static (no motion), subtle (fades / entrance only), rich (keyframes, staggered reveals, looping visuals). If animated, plan to use CSS `@keyframes` / inline `style` + `useEffect`; no extra libraries.
+
+After those four, ask follow-ups **only if still unclear**: brand colors, required assets. Don't pad the conversation with questions already answered.
+
+## Step 3 — Pick a slide id
+
+Use **kebab-case**, short, descriptive. Examples: `rust-intro`, `q2-roadmap`, `team-offsite-2026`. Check `slides/` to avoid collisions.
+
+## Step 4 — Plan the structure
+
+Sketch the slide as a list of page roles before writing code. Common page types:
+
+| Role             | Purpose                                       |
+| ---------------- | --------------------------------------------- |
+| Cover            | Title + subtitle, strong visual               |
+| Agenda           | What's coming (3–5 items)                     |
+| Section divider  | Big label between chapters                    |
+| Content          | Heading + 2–5 bullets OR heading + one visual |
+| Big number       | One statistic the size of the canvas          |
+| Quote            | Pull-quote with attribution                   |
+| Comparison       | Two-column before/after or A vs B             |
+| Closing          | CTA, thanks, contact                          |
+
+**Rule of thumb**: one idea per page. If you're tempted to put two, split them.
+
+If the deck topic naturally calls for specific real images the user must supply (product screenshots, team photos, customer dashboards), plan where those go and use `<ImagePlaceholder>` from `@open-aippt/core` — see the **Image placeholders** section in `slide-authoring`. Default is **no placeholders**: only insert one when a real image is genuinely required.
+
+## Step 5 — Commit to a visual direction
+
+Pick one coherent palette / type scale / aesthetic and hold it across every page. The full set of constraints (palette structure, type scale, padding, aesthetic options) lives in `slide-authoring` — apply it.
+
+**Default: declare a top-level `export const design: DesignSystem = { … }`** at the top of `index.tsx` (after imports) using the chosen palette / type scale, and reference the values via `var(--osd-X)` from inline styles. This keeps the slide tweakable from the Design panel after generation, which is what the user almost always wants. Only skip the `design` const for a one-off slide whose palette is intentionally locked and not meant to be re-themed — in that case, fall back to the local `palette` constants pattern. The "Design system" section of `slide-authoring` covers the format and available tokens.
+
+Consult the `frontend-design` skill for deeper aesthetic guidance if the user wants something bold.
+
+## Step 6 — Write `slides/<id>/index.tsx`
+
+Read the **`slide-authoring`** skill before writing — it covers the file contract, canvas rules, type scale, spacing, and asset imports, and it includes a starter template you can copy. Don't duplicate that knowledge here; use it.
+
+## Step 7 — Self-review
+
+Run the checklist in `slide-authoring` ("Self-review before finishing"). It covers structural correctness, layout discipline, and asset existence.
+
+## Step 8 — Hand off to the user
+
+Tell the user:
+
+- The slide id and file path you created.
+- That the dev server will hot-reload — they can open `http://localhost:5173/s/<id>` (or refresh the home page).
+- If dev isn't running: `pnpm dev` from the repo root.
+
+Don't run the dev server yourself unless asked.

package/skills/create-theme/SKILL.md

@@ -0,0 +1,250 @@
+---
+name: create-theme
+description: Use this skill when the user wants to create, draft, author, or extract a slide theme in this open-aippt repo. Triggers on phrases like "create a theme", "make a theme called X", "extract a theme from <slide>", "build a theme from these images". Produces two paired files under `themes/` — `<id>.md` (palette, typography, layout, fixed Title/Footer components, motion) and `<id>.demo.tsx` (a runnable demo slide that the dev-UI Themes panel previews). Do NOT use for editing real slides — only for authoring the theme bundle.
+---
+
+# Create a slide theme
+
+This skill produces a **theme bundle** under `themes/`: two paired files that together describe a reusable visual identity.
+
+1. `themes/<id>.md` — agent-facing documentation: palette, typography, layout, fixed Title/Footer/Eyebrow components, motion. This is what `create-slide` reads when an author picks the theme.
+2. `themes/<id>.demo.tsx` — a runnable mini-slide (a normal slide module: `export default Page[]`) that demonstrates the theme on 2–3 pages. The dev UI's **Themes panel** loads this file and renders it as the theme's live preview.
+
+Both files share the same stem so the runtime can pair them automatically.
+
+A theme is **distinct from a slide's `design` const**. The theme markdown is authoring-time aesthetic direction (copied into a real slide's source by `create-slide`). The demo `.tsx` is a self-contained preview, not a real slide — it does not appear in the slides list. A per-slide `const design: DesignSystem = { … }` (declared at the top of `slides/<id>/index.tsx`) is the runtime tokens object the user can tweak from the Design panel. The markdown commits the *direction*; the per-slide `design` const makes the slide *tweakable*; the demo `.tsx` makes the theme *previewable*.
+
+You only write files under `themes/<id>.md` and `themes/<id>.demo.tsx`. Never modify real slides or other configuration. The canvas / type-scale defaults that themes can override live in the **`slide-authoring`** skill — read it before writing the theme so your overrides are stated explicitly.
+
+## Step 1 — Identify the input source
+
+A theme can be derived from any combination of three input shapes:
+
+- **Image references** — paths or URLs to slide screenshots, mood-board images, brand assets.
+- **Free-text description** — prose describing the desired palette, fonts, feel.
+- **An existing slide** — `slides/<id>/index.tsx` whose visual identity should be lifted out into a reusable theme.
+
+If the user's original message already specifies the inputs unambiguously, skip the question and proceed. Otherwise call `AskUserQuestion` (multi-select) so they can pick one or more sources, and ask follow-ups (paths, slide id, prose) only as needed.
+
+## Step 2 — Gather raw inputs
+
+- **Images**: read each path with the `Read` tool (it accepts images). Note dominant colors as hex, type weight/style, layout rhythm, decorative motifs, and any recurring chrome (header bar, footer line, page numbers).
+- **Text**: extract explicit tokens (hex codes, font names, motion verbs) and implicit tone words ("editorial", "playful", "brutalist"). Resolve vague language into concrete decisions before writing.
+- **Existing slide**: read `slides/<id>/index.tsx` and pull:
+  - The `palette` object → Palette section.
+  - Font constants and any `font-size` patterns → Typography section.
+  - Padding / alignment patterns → Layout section.
+  - Recurring components (TrafficLights, Eyebrow, Footer-style helpers, WindowShell, …) → Fixed components section.
+  - `@keyframes` blocks and the shared `styles` string → Motion section.
+  - The aesthetic feel implied by the design → Aesthetic paragraph.
+
+When inputs disagree (e.g. images use blue but the description says green), ask the user which to honor.
+
+## Step 3 — Pick a theme id
+
+Use **kebab-case**, short, descriptive. Examples: `editorial-noir`, `brutalist-mono`, `pastel-soft`, `dev-terminal`. Check `themes/` to avoid collisions.
+
+## Step 4 — Write `themes/<id>.md`
+
+Produce a file with this exact section order. Section bodies adapt to the theme; the headings stay consistent across all themes.
+
+````markdown
+---
+name: <Human title, e.g. "Editorial Noir">
+description: <one-line elevator pitch>
+---
+
+# <Theme name>
+
+## Palette
+
+| Role   | Value     | Notes                          |
+| ------ | --------- | ------------------------------ |
+| bg     | `#0f172a` | page background                |
+| text   | `#f8fafc` | primary copy                   |
+| accent | `#fbbf24` | callouts, eyebrow, key numbers |
+| muted  | `#94a3b8` | secondary copy, dividers       |
+| ...    | ...       | extend as the theme requires   |
+
+## Typography
+
+- Display font: `<stack>` — weight 800–900 for headlines.
+- Body font: `<stack>` — weight 400–500.
+- Type-scale overrides (only list what differs from `slide-authoring` defaults):
+  - Hero title: 180 px (default 140–200 ✓)
+  - Body text: 36 px
+
+## Layout
+
+- Content padding: 120 px from canvas edges (1920 × 1080).
+- Alignment: left-aligned, single column.
+- Grid notes: optional 12-column overlay at 80 px gutter for content pages.
+
+## Fixed components
+
+These are paste-ready. Copy them verbatim into a slide that uses this theme.
+
+### Title
+
+```tsx
+const Title = ({ children }: { children: React.ReactNode }) => (
+  <h1
+    style={{
+      fontSize: 140,
+      fontWeight: 900,
+      lineHeight: 1.05,
+      letterSpacing: '-0.02em',
+      margin: 0,
+      color: '#f8fafc',
+    }}
+  >
+    {children}
+  </h1>
+);
+```
+
+### Footer
+
+Pull the page number from `useSlidePageNumber()` — never hardcode `pageNum` / `total` props.
+
+```tsx
+import { useSlidePageNumber } from '@open-aippt/core';
+
+const Footer = () => {
+  const { current, total } = useSlidePageNumber();
+  return (
+    <div
+      style={{
+        position: 'absolute',
+        left: 120,
+        right: 120,
+        bottom: 60,
+        display: 'flex',
+        justifyContent: 'space-between',
+        fontSize: 24,
+        color: '#94a3b8',
+      }}
+    >
+      <span>EDITORIAL NOIR · 2026</span>
+      <span>{current} / {total}</span>
+    </div>
+  );
+};
+```
+
+### Eyebrow / accents (optional)
+
+```tsx
+const Eyebrow = ({ children }: { children: React.ReactNode }) => (
+  <div style={{ fontSize: 26, letterSpacing: '0.2em', color: '#fbbf24' }}>
+    {children}
+  </div>
+);
+```
+
+## Motion
+
+- Philosophy: static / subtle / rich — pick one and explain in one sentence.
+- Reusable keyframes (paste-ready, only if the philosophy is subtle or rich):
+
+```css
+@keyframes fadeUp {
+  from { opacity: 0; transform: translateY(24px); }
+  to   { opacity: 1; transform: translateY(0); }
+}
+```
+
+## Aesthetic
+
+One paragraph. What it feels like, the references it draws on, what to avoid (e.g. "no rounded corners; no gradients; no decorative emoji"). Commit to a single direction — minimal, maximalist, editorial, retro, brutalist, soft/pastel, neon, paper/print.
+
+## Example usage
+
+```tsx
+const Cover: Page = () => (
+  <div style={{ width: '100%', height: '100%', background: '#0f172a', color: '#f8fafc', padding: 120, display: 'flex', flexDirection: 'column', justifyContent: 'center' }}>
+    <Eyebrow>CHAPTER 01</Eyebrow>
+    <Title>The Big Idea</Title>
+    <p style={{ fontSize: 36, color: '#94a3b8', maxWidth: 1200, marginTop: 32 }}>
+      A short subtitle that explains what this slide is about.
+    </p>
+    <Footer />
+  </div>
+);
+```
+````
+
+## Step 4b — Write `themes/<id>.demo.tsx`
+
+The demo is a normal slide module — same shape as `slides/<id>/index.tsx`, just sitting under `themes/` so the runtime knows it's preview-only. The dev-UI Themes panel imports it and renders it inside `SlideCanvas` (1920×1080).
+
+Contract:
+
+- `import { type Page, useSlidePageNumber } from '@open-aippt/core';`
+- Inline the **same** `Title`, `Footer`, `Eyebrow` components defined in the theme markdown — verbatim, no abstractions, no imports from elsewhere. The demo and the markdown must stay in lockstep so what the user sees in the panel matches what `create-slide` will paste into a real slide.
+- Export 2–3 `Page` components and a default array. Aim for: a Cover (Eyebrow + Title + subtitle), one Content page exercising body type + accent, and a Closer or "End" card. The "Example usage" block at the bottom of the markdown is a good starting point — extend it.
+- If the theme has runtime-tweakable tokens worth surfacing in the Design panel later, also `export const design: DesignSystem = {...}`.
+- No external assets, no `import` from `@/`, no slides-only helpers (e.g. `WindowShell` from a real slide). Demo files must be self-contained.
+
+Skeleton:
+
+```tsx
+import { type Page, useSlidePageNumber } from '@open-aippt/core';
+
+const Title = ({ children }: { children: React.ReactNode }) => (
+  // …same JSX as in themes/<id>.md
+);
+const Footer = () => {
+  const { current, total } = useSlidePageNumber();
+  // …
+};
+const Eyebrow = ({ children }: { children: React.ReactNode }) => (
+  // …
+);
+
+const Cover: Page = () => (
+  // …
+);
+const Content: Page = () => (
+  // …
+);
+const Closer: Page = () => (
+  // …
+);
+
+export default [Cover, Content, Closer];
+```
+
+## Step 5 — Self-review
+
+Run this checklist before finishing:
+
+- [ ] Palette covers `bg` / `text` / `accent` / `muted` at minimum, all as hex.
+- [ ] Type scale specifies hero, heading, body, caption sizes (or explicitly defers to `slide-authoring` defaults).
+- [ ] At least Title and Footer are defined as paste-ready React with concrete inline styles.
+- [ ] Motion section commits to one of static / subtle / rich.
+- [ ] Aesthetic paragraph names a single coherent direction.
+- [ ] Both files written: `themes/<id>.md` and `themes/<id>.demo.tsx`. No slide changes, no config changes.
+- [ ] Demo `.tsx` exports 2–3 pages and inlines the same Title/Footer/Eyebrow components defined in the markdown.
+- [ ] Demo opens cleanly in the **Themes** panel of the dev UI — re-checked by you only by reading the file (do not start a server).
+
+## Step 6 — Hand off
+
+Tell the user:
+
+- The theme id and the two file paths (`themes/<id>.md` + `themes/<id>.demo.tsx`).
+- That the demo will appear in the dev UI's **Themes** panel as a live card and detail view (HMR — no restart needed).
+- That `/create-slide` will list the theme as a picker option on its next run.
+- A one-line summary of the look (palette + aesthetic).
+
+Do not run the dev server. Do not modify real slides — even to demonstrate the theme; the demo `.tsx` is the demonstration.
+
+## Anti-patterns
+
+- ❌ Writing executable code in `themes/<id>.md` outside the labeled component snippets — the markdown is documentation.
+- ❌ Producing only the markdown without the demo, or only the demo without the markdown. A theme is the **bundle** — both files, every time.
+- ❌ Treating `themes/<id>.demo.tsx` as a real slide. It is preview-only and lives outside the slides list; never put it under `slides/`.
+- ❌ Importing from `@/` or any slide-specific helper inside the demo. The demo is self-contained.
+- ❌ Inventing palette / fonts when the user supplied images or an existing slide. Extract, don't fabricate.
+- ❌ Editing `slides/`, `packages/`, `package.json`, or `open-aippt.config.ts`.
+- ❌ Skipping the Fixed components section. Title and Footer are the most common reuse target — they must be paste-ready.

package/skills/current-slide/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: current-slide
+description: Resolve which slide, page, and (optionally) selected element the user is currently viewing in the open-aippt dev server. Consult this whenever the user references "this page", "this slide", "this element", "the slide I'm on", "the current page", or any deictic reference to slide content without naming it. Re-read `node_modules/.open-aippt/current.json` at the start of every such turn — the user navigates between turns, so a value you read earlier in the conversation is almost certainly stale.
+---
+
+# Where is the user right now?
+
+When the user says "fix this page", "tweak this heading", or "the slide I'm looking at", they almost never name the slide id, page number, or element — they mean wherever they are in the dev viewer. Before asking "which slide?" or "which element?", check the file the dev server writes on every navigation and inspector pick.
+
+## Re-read on every deictic turn — never reuse a prior read
+
+`current.json` is a live cursor, not a fact about the conversation. The user moves between slides, pages, and elements freely between your turns — including while you were doing other work. **Read the file fresh at the start of every new turn that uses a deictic reference**, even if:
+
+- you already read it earlier in this same conversation,
+- you just finished editing the slide it pointed to,
+- the user's new message sounds like a continuation ("now make it bigger", "also fix this one", "keep going").
+
+A "continue editing" follow-up is exactly the case where the user has likely just navigated to a different slide or picked a different element. Trusting your last read here will silently edit the wrong file. Re-read, compare `slideId` / `pageIndex` / `selection` against what you used last time, and act on the new values.
+
+## How to read it
+
+```
+node_modules/.open-aippt/current.json
+```
+
+Path is relative to the project root (the user's `cwd`, the directory that contains `slides/` and `package.json`). Use the `Read` tool. The file is JSON.
+
+## What you get
+
+```json
+{
+  "slideId": "q2-roadmap",
+  "pageIndex": 2,
+  "pageNumber": 3,
+  "totalPages": 8,
+  "slideTitle": "Q2 Roadmap",
+  "view": "slides",
+  "pagePath": "slides/q2-roadmap/index.tsx",
+  "selection": {
+    "line": 42,
+    "column": 6,
+    "tagName": "h1",
+    "text": "Q2 Roadmap"
+  },
+  "updatedAt": "2026-05-09T14:32:11.123Z"
+}
+```
+
+- `slideId` — folder name under `slides/`. Use as-is for any `/__slides/<id>/...` API or as the URL segment.
+- `pageIndex` — 0-based, for use with the page array in `index.tsx` (`export default [Cover, Body, ...]`).
+- `pageNumber` — 1-based, for use in messages to the user ("page 3 of 8") and for the URL `?p=N`.
+- `pagePath` — relative path to the slide source. Hand straight to `Read` / `Edit`.
+- `view` — `"slides"` (canvas view) or `"assets"` (asset manager). If `"assets"`, the user is browsing files for that slide rather than viewing a page.
+- `selection` — `null` if nothing is selected. Otherwise, the JSX element the user picked in the inspector overlay:
+  - `line` (1-indexed) and `column` (0-indexed) point to the JSX opening tag inside `pagePath`. This is the canonical handle — match against the source line, not the rendered DOM.
+  - `tagName` is the rendered DOM tag, lowercased (`"h1"`, `"div"`, `"img"`).
+  - `text` is a trimmed text snippet (≤120 chars) from the element's `textContent`, useful as a sanity check that you're looking at the right node.
+  - Selection auto-clears whenever the user navigates to a different slide or page.
+- `updatedAt` — ISO timestamp of the last navigation or selection change. Use it to detect staleness.
+
+## When to use this
+
+- The user references the current slide/page deictically: "this", "here", "the page I'm on", "the slide I'm looking at", "what I'm working on".
+- The user references a specific element: "this heading", "this image", "the button I just clicked", "tighten this", "change the color of this". If `selection` is non-null, that's the element they mean.
+- Before asking "which slide?" or "which element?" as a clarifying question — check this file first.
+- Before guessing from `git log`, recently-edited files, or the most recent slide folder.
+
+## When NOT to use this
+
+- The user names a slide explicitly ("edit `q2-roadmap`") — use that name directly.
+- The `apply-comments` workflow already finds the right file via `@slide-comment` markers; it doesn't need this skill.
+- For listing or discovering slides — read `slides/` directly.
+
+## Staleness — verify before acting
+
+`updatedAt` is the last time the user navigated. Treat it like a cache:
+
+- **Fresh (under ~5 minutes old)**: trust it. Open `pagePath`, do the work.
+- **Older than ~5 minutes, or older than your last interaction with the user**: confirm with the user before editing. The dev server may not be running; the user may have switched contexts.
+- **Hours/days old**: ignore it. Ask the user which slide they mean.
+
+A *newer* `updatedAt` than the one you saw last turn is the normal signal that the user has moved — switch to the new `slideId` / `pageIndex` / `selection` without asking.
+
+## When the file is missing
+
+- The dev server hasn't been opened on a slide yet, or has never run.
+- Don't create the file or guess. Ask the user which slide they mean, or suggest they open the slide in the dev server first.
+
+## Example — page-level reference
+
+User: "tighten the spacing on this page"
+
+1. Read `node_modules/.open-aippt/current.json`.
+2. Check `updatedAt` is recent.
+3. Read `pagePath` (e.g. `slides/q2-roadmap/index.tsx`).
+4. Identify the page at `pageIndex` in the default-exported array.
+5. Consult the `slide-authoring` skill for spacing rules, then edit that page in place.
+
+If `current.json` is missing or stale, ask: "Which slide and page should I tighten? The dev server hasn't published a current page recently."
+
+## Example — element-level reference
+
+User: "make this bigger"
+
+1. Read `node_modules/.open-aippt/current.json`.
+2. If `selection` is non-null, the user means that element. Read `pagePath`, jump to `selection.line`, and find the JSX opening tag near that line/column. Confirm with the snippet in `selection.text` and the `tagName`.
+3. Consult `slide-authoring` for type-scale and layout rules before editing.
+4. Edit the JSX node in place.
+
+If `selection` is null, fall back to the page-level flow above — and consider asking "which element?" since the user used a deictic but hasn't picked one in the inspector.