@autono/open-pages 0.1.0

package/package.json

@@ -0,0 +1,106 @@
+{
+  "name": "@autono/open-pages",
+  "version": "0.1.0",
+  "description": "Runtime and CLI for open-pages — live preview of React and HTML pages, click-to-comment inspector, and static export.",
+  "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-pages": "./bin.js"
+  },
+  "files": [
+    "bin.js",
+    "dist",
+    "env.d.ts",
+    "src/app",
+    "src/locale",
+    "skills",
+    "README.md"
+  ],
+  "scripts": {
+    "build": "tsdown",
+    "typecheck": "tsc --noEmit",
+    "test:e2e": "pnpm run build && playwright test",
+    "prepack": "pnpm build"
+  },
+  "engines": {
+    "node": ">=18"
+  },
+  "keywords": [
+    "pages",
+    "website",
+    "landing-page",
+    "react",
+    "vite",
+    "agents",
+    "tailwind",
+    "html"
+  ],
+  "license": "MIT",
+  "author": {
+    "name": "autonoco",
+    "url": "https://github.com/autonoco"
+  },
+  "homepage": "https://openpages.sh",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/autonoco/open-pages.git",
+    "directory": "packages/core"
+  },
+  "bugs": {
+    "url": "https://github.com/autonoco/open-pages/issues"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "dependencies": {
+    "@babel/parser": "^8.0.4",
+    "@babel/types": "^8.0.4",
+    "@base-ui/react": "1.6.0",
+    "@fontsource-variable/geist": "^5.2.8",
+    "@tailwindcss/vite": "^4.3.3",
+    "@vitejs/plugin-react": "^4.3.3",
+    "chalk": "^6.0.0",
+    "class-variance-authority": "^0.7.1",
+    "clsx": "^2.1.1",
+    "cmdk": "^1.1.1",
+    "commander": "^15.0.0",
+    "emoji-picker-react": "^4.19.1",
+    "fast-glob": "^3.3.2",
+    "lucide-react": "^1.25.0",
+    "next-themes": "^0.4.6",
+    "react": "^18.3.1",
+    "react-dom": "^18.3.1",
+    "react-router-dom": "^7.18.1",
+    "shadcn": "^4.19.0",
+    "sonner": "^2.0.7",
+    "tailwind-merge": "^3.5.0",
+    "tailwindcss": "^4.2.2",
+    "tw-animate-css": "^1.4.0",
+    "use-sync-external-store": "^1.6.0",
+    "vite": "^5.4.10"
+  },
+  "devDependencies": {
+    "@playwright/test": "~1.62.1",
+    "@types/node": "^22.19.17",
+    "@types/react": "^18.3.12",
+    "@types/react-dom": "^18.3.1",
+    "tsdown": "^0.9.9",
+    "typescript": "^5.9.3"
+  }
+}

package/skills/apply-comments/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: apply-comments
+description: Apply pending @page-comment markers written by the open-pages inspector tool. Use when the user asks to "apply comments", "process page comments", "apply the inspector comments", or references markers left inside `pages/<id>/index.tsx` (or its `components/*.tsx`).
+---
+
+# Apply page comments
+
+The open-pages viewer has an inspector that lets the user click any element on the live page and attach a textual comment (e.g. *"make this red"*, *"change to 'Open Pages Rocks'"*). Each comment is persisted as an in-source JSX marker inside the page's source — usually `pages/<pageId>/index.tsx`, occasionally a file under `pages/<pageId>/components/`.
+
+Your job: read those markers, perform the described edits, and delete the markers.
+
+> **Before making any page edit**, consult the **`page-authoring`** skill — it is the technical reference for how a page is structured (file contract, `className` styling, layout and responsive rules, type scale, interactivity). A comment like *"make this bigger"* or *"change the accent colour"* should be applied in a way that stays consistent with those rules and still works on mobile.
+
+## Marker format
+
+```
+{/* @page-comment id="c-<8hex>" ts="<ISO>" text="<base64url(JSON)>" */}
+```
+
+- Inserted as the **first child inside** the JSX element it refers to: a newline + indent + the marker, spliced immediately after the element's opening `>`. The marker is dropped *into* its target, not floated above it. **The marker does not necessarily end its line** — for an element that was written on one line (`<h1>Title</h1>`), the element's children and closing tag follow the marker on the same line.
+- `text` is base64url-encoded JSON: `{"note": "...", "hint"?: "..."}`.
+- Detection regex (authoritative — use exactly this):
+
+  ```
+  /\{\/\*\s*@page-comment\s+id="(c-[a-f0-9]+)"\s+ts="([^"]+)"\s+text="([A-Za-z0-9_\-]+={0,2})"\s*\*\/\}/g
+  ```
+
+## Procedure
+
+1. **Identify the target page(s).**
+   - If the user names one (`launch`, `pricing`, etc.), work on that single page's source files.
+   - If they say "all" or don't specify, scan every `pages/*/index.tsx` and `pages/*/components/*.tsx`. Process each page 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), 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, `className` strings, any state the element depends on) to apply the change faithfully. A comment inside a `<button>` with an `onClick` may be about behaviour, not looks.
+   - If the marker sits inside a `.map` body, the comment applies to the row template — every rendered row changes. If the user clearly meant one item ("make the *middle* one green"), change the data or add a per-item field rather than special-casing the JSX.
+   - 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 **only the marker text itself** — the `{/* @page-comment … */}` span matched by the detection regex — plus the newline and indentation immediately *before* it (the whitespace the inspector inserted). Never delete the whole line: children and the closing tag often share the marker's line, and removing the line destroys them.
+   - After removal, if the element is left split across two lines that were originally one (`<h1 …>\n  Title</h1>`), it is fine to rejoin them, but not required.
+   - Never leave a marker behind for an edit you applied — that signals a failure. Markers deliberately skipped per the edge cases below stay in place.
+
+6. **Verify.**
+   - After all edits, re-read the file and confirm the only remaining markers are ones you reported as skipped.
+   - Confirm the edited JSX is well-formed (balanced tags, no dangling attributes) and that changed `className` strings are literal Tailwind utilities. If the project's `package.json` has typecheck/lint scripts, run them with the project's package manager; scaffolded projects ship neither TypeScript nor a linter — there, rely on the running dev server (or the `build` script) to surface compile errors. Fix any errors you introduced.
+   - For layout changes, mentally check the Mobile viewport (390px): did the edit introduce a fixed width or a grid with no stacking fallback?
+
+7. **Report.**
+   - Summarise: `N applied, M skipped` plus a one-line description of each change (including the page 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. Read their notes in source order to understand the combined intent, then apply and delete them bottom-up per step 4.
+- **Comment asks for something outside the target element's scope** (e.g. "add a testimonials section"): do the closest-reasonable edit and mention the scope expansion in your summary.
+- **Comment on a plain HTML page** (`pages/<id>/index.html`): the inspector does not run there, so no markers exist. Apply the user's request directly to the HTML.
+- **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-pages.config.ts`, or files outside `pages/`.
+- Do not add dependencies.
+- Do not re-introduce markers or leave `TODO` breadcrumbs — the user already has a record in git.

package/skills/create-page/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: create-page
+description: Use this skill when the user wants to create, build, draft, or generate a new web page, site, or landing page in this open-pages repo. Triggers on phrases like "make a landing page for X", "build a pricing page", "create a portfolio site", "new page", "a dashboard UI", "an HTML page", or when the user asks to add content under `pages/`. Do NOT use for editing the framework itself — only for authoring content inside `pages/<id>/`.
+---
+
+# Create a page in open-pages
+
+This skill owns the **workflow** for building a new page. The technical reference — file contract, Tailwind via `className`, layout and responsive rules, type scale, interactivity, assets — lives in the **`page-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 `pages/<id>/`. Never modify `package.json`, `open-pages.config.ts`, or existing pages.
+
+## 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. (`AskUserQuestion` holds at most 4 options — with 4+ themes, offer the 3 most topic-relevant plus "no theme"; the auto-added "Other" lets the user name any omitted theme.)
+
+- If the user picks a theme: read `themes/<id>.md` end-to-end. The theme's palette, typography, and fixed components are now authoritative — copy them directly into the page. **Also set `theme: '<theme-id>'` on the `meta` export** so the page back-links to the theme. In Step 2, skip the **visual direction** question (the theme already commits to one); confirm the page's purpose itself before moving on. Sections and interactivity are independent of theme — ask those normally.
+- If the user picks "no theme", or `themes/` contains no theme markdown files: proceed to Step 2 unchanged.
+
+If you skip the visual-direction 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 key decisions below via `AskUserQuestion`.** They shape every downstream choice, so locking them in up front avoids rework. Only skip a question when it's already unambiguously answered — by the user's original message, or by a theme picked in Step 1 — and if you skip, restate your assumption so they can correct it.
+
+**Purpose comes first.** If the user's initial request is thin ("make me a page", "build a site"), make a *separate* `AskUserQuestion` call first to gather what the page is for, who lands on it, and what content they already have (copy, product names, prices, screenshots, links). Skip this only if already clear — then restate your reading so they can correct course.
+
+Then ask these four in a single `AskUserQuestion` call (multi-question form):
+
+1. **Page type** — offer the closest fits: landing / marketing page, product or pricing page, dashboard or app UI, docs or long-form content page, portfolio or personal site, form or signup flow, internal tool. Mark the best fit "(Recommended)". This drives structure and how much interactivity to expect.
+
+2. **Visual direction** — propose 3 directions tailored to *this* page and its audience. Do **not** pull from a fixed preset list. Each option must combine a vibe word + a concrete visual cue (palette, weight, surfaces) so the user can picture it; bare labels like "modern" are too vague. The three options should feel meaningfully different.
+
+   How options should shift with page type:
+   - *SaaS landing page* → **dark launch** (near-black, one neon accent, large display type) · **clean product** (white, slate text, one indigo accent, soft cards) · **editorial** (warm off-white, serif display, generous whitespace)
+   - *Dashboard* → **ops console** (dense, slate surfaces, status colors) · **calm workspace** (airy, rounded cards, one accent) · **data-forward** (tables and charts as the spine, mono numerals)
+   - *Portfolio* → **gallery** (big imagery, minimal chrome) · **typographic** (type does the work, one accent) · **playful** (color blocks, rounded shapes, motion)
+
+   Mark the best fit "(Recommended)". (`AskUserQuestion` auto-adds "Other" — don't add a catch-all yourself.)
+
+3. **Sections / content** — offer bundles that fit the type, e.g. for a landing page: hero + features + pricing + FAQ + footer (Recommended); hero + social proof + CTA (short); hero + long-form explainer + CTA. The auto-added "Other" covers custom lists.
+
+4. **Interactivity** — offer: static (links only), light (tabs, toggles, accordions, a pricing switch), form (a contact/signup form that mirrors state locally or posts to a URL they supply), app-like (filters, local state, multiple views). Note that no backend exists — anything that needs one requires a URL from the user.
+
+After those, ask follow-ups **only if still unclear**: brand colors, logo/screenshots, real copy (headlines, prices, names). Real pages live on real content — placeholder copy like "Acme, $10/mo" is a last resort; prefer asking for the real values. Responsive is not a question: every page must work at Desktop, Tablet (820px), and Mobile (390px).
+
+## Step 3 — Pick a page id
+
+Use **kebab-case**, short, descriptive. Examples: `launch`, `pricing`, `status-board`, `founder-portfolio`, `waitlist`. Check `pages/` to avoid collisions.
+
+## Step 4 — Plan the structure
+
+Sketch the page as an ordered list of sections before writing code. Common shapes:
+
+| Section | Purpose |
+| --- | --- |
+| Header / nav | Wordmark, 3–5 links, one CTA; collapses on mobile |
+| Hero | One headline, one lede, primary + secondary CTA, optional visual |
+| Social proof | Logos, a metric row, one quote |
+| Features | 3–6 cards or alternating rows, each one benefit |
+| Pricing | 2–3 tiers, a billing toggle, clear CTA per tier |
+| FAQ | Accordion or plain list |
+| CTA band | Restate the ask before the footer |
+| Footer | Links, legal line |
+| App shell | Sidebar/topbar + content area for dashboards and tools |
+
+**Rule of thumb:** one idea per section, one CTA per screen. If a section lists things, it wants a grid or a table, not a paragraph.
+
+Decide the data shape now: which sections render from a typed const array (`.map`), which are explicit component instances — `page-authoring` explains why this matters for the inspector.
+
+## Step 5 — Commit to a visual direction
+
+One palette, one type scale, held for the whole page. The constraints (web type scale, palette structure, contrast) live in `page-authoring` and its `references/typography-and-color.md` — apply them. Define the palette as repeated Tailwind utilities (or a small const map of class strings). Fonts: default to the system stack; load a Google Font or self-hosted file only when the user names one or a theme requires it (`references/assets-and-fonts.md`).
+
+## Step 6 — Write `pages/<id>/index.tsx`
+
+Read the **`page-authoring`** skill before writing — file contract, `className` styling, layout and responsive rules, interactivity constraints, assets. Its file-contract example is the starter template. Split large pages into `pages/<id>/components/*.tsx` when a section is more than ~80 lines.
+
+## Step 7 — Self-review
+
+Run the checklist in `page-authoring` ("Self-review before finishing"). Check all three viewports.
+
+## Step 8 — Hand off to the user
+
+Tell the user:
+
+- The page id and file path you created.
+- The preview URL — `http://localhost:5173/p/<id>` — hot-reloads on every edit, with Desktop / Tablet / Mobile toggles and **Open** to view the page by itself.
+- That they can hit **Inspect** (or `i`) in the preview, click any element, and leave comments — then ask you to run `apply-comments`.
+- That `open-pages export <id>` writes `export/<id>/` — a static folder (index.html + assets) they can deploy to Netlify, Vercel, Cloudflare Pages, GitHub Pages, or any static host.
+- If dev isn't running: run the project's `dev` script from the project root with its package manager (`npm run dev`, `pnpm dev`, … — match the lockfile).
+
+Don't run the dev server yourself unless asked.

package/skills/create-theme/SKILL.md

@@ -0,0 +1,223 @@
+---
+name: create-theme
+description: Use this skill when the user wants to create, draft, author, or extract a page theme in this open-pages repo. Triggers on phrases like "create a theme", "make a theme called X", "extract a theme from <page>", "build a design system from these screenshots", "match our brand". Produces two paired files under `themes/` — `<id>.md` (palette, typography, layout, fixed components) and `<id>.demo.tsx` (a runnable demo page the workspace's Themes panel previews live). Do NOT use for editing real pages — only for authoring the theme bundle.
+---
+
+# Create a page theme
+
+This skill produces a **theme bundle** under `themes/`: two paired files that together describe a reusable visual identity for web pages.
+
+1. `themes/<id>.md` — agent-facing documentation: palette, typography, layout, fixed components (nav, hero, section wrapper, buttons, card, footer). This is what `create-page` reads when an author picks the theme.
+2. `themes/<id>.demo.tsx` — a runnable demo page (same module shape as `pages/<id>/index.tsx`: **one default-exported component**) that shows the theme on a single scrolling page. The workspace's Themes panel renders it live, exactly like a real page.
+
+Both files share the same stem so the runtime can pair them automatically.
+
+The theme markdown is authoring-time direction — `create-page` copies its palette, utilities, and components into a real page's source. The demo `.tsx` is a self-contained preview, not a real page — it does not appear in the pages list.
+
+You only write `themes/<id>.md` and `themes/<id>.demo.tsx`. Never modify real pages or configuration. The styling rules and web defaults that themes override live in the **`page-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 screenshots, mood-board images, brand assets.
+- **Free-text description** — prose describing the desired palette, weight, feel.
+- **An existing page** — `pages/<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, page 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 and family feel, corner radius, surface treatment (flat vs. cards vs. borders), density, and recurring chrome (nav style, footer).
+- **Text**: extract explicit tokens (hex codes, font names, tone words) and resolve vague language into concrete decisions before writing.
+- **Existing page**: read `pages/<id>/index.tsx` (and `components/`) and pull:
+  - The Tailwind color utilities used consistently (`bg-…`, `text-…`, accent classes) → Palette section.
+  - Type sizes and any font loading (`<link>` to Google Fonts, `font-[…]`) → Typography section.
+  - Container widths, section padding, breakpoints used → Layout section.
+  - Recurring helper components (nav, hero, cards, buttons, footer) → Fixed components section.
+  - The aesthetic feel implied → 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: `dark-launch`, `clean-saas`, `editorial-warm`, `ops-console`. 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. "Dark Launch">
+description: <one-line elevator pitch>
+---
+
+# <Theme name>
+
+## Palette
+
+| Role | Tailwind | Hex | Notes |
+| --- | --- | --- | --- |
+| background | `bg-[#0b0b10]` | #0b0b10 | page root |
+| surface | `bg-white/[0.04] border-white/10` | — | cards, panels |
+| text | `text-white` | #ffffff | headings, body |
+| muted | `text-white/60` | — | secondary copy, labels |
+| accent | `bg-emerald-400 text-black` / `text-emerald-400` | #34d399 | primary CTA, eyebrows |
+| border | `border-white/10` | — | dividers, card edges |
+
+## Typography
+
+- Font: system stack, or a named family with how to load it (Google Fonts `<link>` rendered in the page, or a self-hosted file the page must place under `assets/`).
+- Type-scale overrides (only list what differs from `page-authoring` defaults):
+  - Hero heading: `text-5xl sm:text-7xl font-bold leading-[1.02] tracking-tight`
+  - Section heading: `text-3xl font-bold tracking-tight`
+  - Body: `text-lg text-white/60`
+  - Eyebrow: `text-xs font-semibold uppercase tracking-[0.25em] text-emerald-400`
+
+## Layout
+
+- Container: `mx-auto max-w-6xl px-6`.
+- Section rhythm: `py-20`, sections separated by `border-t border-white/10`.
+- Breakpoints: single column by default; `sm:grid-cols-3` for feature and pricing grids; nav links `hidden sm:flex`.
+- Radius: `rounded-full` for buttons, `rounded-2xl` for cards.
+
+## Fixed components
+
+These are paste-ready React JSX with `className`. Copy them verbatim into a page that uses this theme.
+
+### Nav
+
+```tsx
+const Nav = ({ brand, links, cta }: { brand: string; links: { label: string; href: string }[]; cta: { label: string; href: string } }) => (
+  <header className="mx-auto flex max-w-6xl items-center justify-between px-6 py-6">
+    <span className="font-semibold tracking-tight">{brand}</span>
+    <nav className="hidden gap-8 text-sm text-white/70 sm:flex">
+      {links.map((l) => (
+        <a key={l.href} href={l.href} className="hover:text-white">{l.label}</a>
+      ))}
+    </nav>
+    <a href={cta.href} className="rounded-full bg-white px-4 py-2 text-sm font-medium text-black hover:bg-white/90">{cta.label}</a>
+  </header>
+);
+```
+
+### Hero
+
+```tsx
+const Hero = ({ eyebrow, title, lede, children }: { eyebrow: string; title: string; lede: string; children?: React.ReactNode }) => (
+  <section className="mx-auto max-w-6xl px-6 pt-20 pb-24 text-center">
+    <p className="text-xs font-semibold uppercase tracking-[0.25em] text-emerald-400">{eyebrow}</p>
+    <h1 className="mx-auto mt-6 max-w-3xl text-5xl font-bold leading-[1.02] tracking-tight sm:text-7xl">{title}</h1>
+    <p className="mx-auto mt-6 max-w-xl text-lg text-white/60">{lede}</p>
+    <div className="mt-10 flex flex-col justify-center gap-3 sm:flex-row">{children}</div>
+  </section>
+);
+```
+
+### Section
+
+```tsx
+const Section = ({ id, children }: { id?: string; children: React.ReactNode }) => (
+  <section id={id} className="border-t border-white/10">
+    <div className="mx-auto max-w-6xl px-6 py-20">{children}</div>
+  </section>
+);
+```
+
+### Buttons
+
+```tsx
+const PrimaryButton = ({ href, children }: { href: string; children: React.ReactNode }) => (
+  <a href={href} className="rounded-full bg-emerald-400 px-6 py-3 font-medium text-black hover:bg-emerald-300">{children}</a>
+);
+const SecondaryButton = ({ href, children }: { href: string; children: React.ReactNode }) => (
+  <a href={href} className="rounded-full border border-white/20 px-6 py-3 font-medium text-white/80 hover:border-white/40">{children}</a>
+);
+```
+
+### Card
+
+```tsx
+const Card = ({ title, children }: { title: string; children: React.ReactNode }) => (
+  <div className="rounded-2xl border border-white/10 bg-white/[0.03] p-6">
+    <h3 className="font-semibold">{title}</h3>
+    <div className="mt-2 text-white/60">{children}</div>
+  </div>
+);
+```
+
+### Footer
+
+```tsx
+const Footer = ({ left, right }: { left: string; right: string }) => (
+  <footer className="border-t border-white/10">
+    <div className="mx-auto flex max-w-6xl items-center justify-between px-6 py-8 text-sm text-white/40">
+      <span>{left}</span>
+      <span>{right}</span>
+    </div>
+  </footer>
+);
+```
+
+## Aesthetic
+
+One paragraph. What it feels like, the references it draws on, what to avoid (e.g. "no gradients; one accent only; borders over shadows; motion limited to hover color changes"). Commit to a single direction.
+
+## Example usage
+
+```tsx
+<main className="min-h-screen bg-[#0b0b10] text-white antialiased">
+  <Nav brand="Meridian" links={links} cta={{ label: 'Get started', href: '#pricing' }} />
+  <Hero eyebrow="Now in public beta" title="Your analytics, turned into decisions" lede="…">
+    <PrimaryButton href="#pricing">Start free</PrimaryButton>
+    <SecondaryButton href="#features">See how it works</SecondaryButton>
+  </Hero>
+  {/* … */}
+  <Footer left="© 2026 Meridian" right="Built with open-pages" />
+</main>
+```
+````
+
+## Step 4b — Write `themes/<id>.demo.tsx`
+
+The demo is a normal page module — same shape as `pages/<id>/index.tsx`, just sitting under `themes/` so the runtime knows it's preview-only.
+
+Contract:
+
+- `import type { PageMeta } from '@autono/open-pages';` and React hooks as needed.
+- **One default-exported component** — a single scrolling page that exercises the theme: nav, hero with both buttons, a section with a card grid, a footer.
+- Inline the **same** fixed components defined in the theme markdown — verbatim, no abstractions. Demo and markdown must stay in lockstep so what `create-page` pastes matches what the demo shows.
+- Root element sets `min-h-screen`, the theme background, and text color. Must look right at Mobile (390px) as well as Desktop.
+- Content should be plausible and realistic, not lorem ipsum. Self-contained: no `@/` imports, no page-local assets; if the theme names a Google Font, render the `<link>` tag in the demo too.
+
+## Step 5 — Self-review
+
+- [ ] Palette table covers background / surface / text / muted / accent / border as Tailwind utilities, with hex where fixed.
+- [ ] Frontmatter has `name` and `description` only (the runtime reads nothing else).
+- [ ] Typography names only fonts the theme explains how to load (or the system stack).
+- [ ] Layout specifies container width, section rhythm, and breakpoints.
+- [ ] Fixed components are paste-ready React JSX (`className`, typed props, no `@/` imports) and cover nav, hero, section, buttons, card, footer.
+- [ ] Aesthetic paragraph names a single coherent direction.
+- [ ] Both files written: `themes/<id>.md` and `themes/<id>.demo.tsx`. No page changes, no config changes.
+- [ ] Demo `.tsx` default-exports one component and inlines the same fixed components as the markdown; contrast holds; nothing overflows on mobile.
+
+## Step 6 — Hand off
+
+Tell the user:
+
+- The theme id and the two file paths.
+- That the Themes panel in the workspace (`http://localhost:5173/themes`) previews the demo live, and `/create-page` 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 pages — 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.
+- ❌ Desktop-only components: a nav with no mobile behaviour, grids with no stacking fallback.
+- ❌ Naming font families the theme never explains how to load.
+- ❌ Inventing palette / styling when the user supplied images or an existing page. Extract, don't fabricate.
+- ❌ Editing `pages/`, `packages/`, `package.json`, or `open-pages.config.ts`.
+- ❌ Skipping Fixed components. Nav, hero, buttons, and footer are the most common reuse targets — they must be paste-ready.

package/skills/current-page/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: current-page
+description: Resolve which page and (optionally) selected element the user is currently viewing in the open-pages dev server. Consult this whenever the user references "this page", "this site", "this element", "the page I'm on", "the button I clicked", or any deictic reference to page content without naming it. Re-read `node_modules/.open-pages/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 page I'm looking at", they almost never name the page id or element — they mean wherever they are in the dev viewer. Before asking "which page?" 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 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 page 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 page or picked a different element. Trusting your last read here will silently edit the wrong file. Re-read, compare `pageId` / `selection` against what you used last time, and act on the new values.
+
+## How to read it
+
+```
+node_modules/.open-pages/current.json
+```
+
+Path is relative to the project root (the user's `cwd`, the directory that contains `pages/` and `package.json`). Use the `Read` tool. The file is JSON.
+
+## What you get
+
+```json
+{
+  "pageId": "launch",
+  "pageTitle": "Meridian — Launch",
+  "view": "pages",
+  "pagePath": "pages/launch/index.tsx",
+  "selection": {
+    "line": 52,
+    "column": 8,
+    "tagName": "h1",
+    "text": "Your analytics, turned into decisions"
+  },
+  "updatedAt": "2026-08-28T14:32:11.123Z"
+}
+```
+
+- `pageId` — folder name under `pages/`. Use as-is for any `/__pages/<id>/...` API or as the URL segment (`/p/<id>`).
+- `pageTitle` — the page's `meta.title` (or `<title>` for an HTML page), falling back to the id.
+- `pagePath` — page entry path **relative to the project root**: `pages/<id>/index.tsx`, or `pages/<id>/index.html` for a plain HTML page. Prefix it with the project root before handing it to `Read` / `Edit`. Note the selection may point into a file under `pages/<id>/components/` if the page is split — match the line against the file whose JSX contains that tag and text.
+- `view` — `"pages"` when the user is viewing the page, `"assets"` when they are browsing that page's files in the asset manager rather than the page itself.
+- `selection` — `null` if nothing is selected. Otherwise, the JSX element the user picked in the inspector:
+  - `line` (1-indexed) and `column` (0-indexed) point to the JSX opening tag in the page source. This is the canonical handle — match against the source line.
+  - `tagName` is the rendered HTML tag, lowercased (`"h1"`, `"div"`, `"button"`).
+  - `text` is a trimmed text snippet (≤120 chars) of the element's content — a sanity check that you're looking at the right node.
+  - Selection auto-clears whenever the user navigates to a different page or clears it in the viewer. HTML pages never produce a selection.
+- `updatedAt` — ISO timestamp of the last navigation or selection change. Use it to detect staleness.
+
+## When to use this
+
+- The user references the current page deictically: "this", "here", "the page I'm on", "the site 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 page?" or "which element?" as a clarifying question — check this file first.
+- Before guessing from `git log`, recently-edited files, or the most recent page folder.
+
+## When NOT to use this
+
+- The user names a page explicitly ("edit `launch`") — use that name directly.
+- The `apply-comments` workflow already finds the right file via `@page-comment` markers; it doesn't need this skill.
+- For listing or discovering pages — read `pages/` 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**: 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 page 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 `pageId` / `selection` without asking.
+
+## When the file is missing
+
+- The dev server hasn't been opened on a page yet, or has never run.
+- Don't create the file or guess. Ask the user which page they mean, or suggest they open the page in the dev server first.
+
+## Example — page-level reference
+
+User: "tighten the spacing on this page"
+
+1. Read `node_modules/.open-pages/current.json`.
+2. Check `updatedAt` is recent.
+3. Read `pagePath` (e.g. `pages/launch/index.tsx`).
+4. If `selection` is set, jump to that line; otherwise identify the relevant section from the user's words.
+5. Consult the `page-authoring` skill for spacing and layout rules, then edit in place.
+
+If `current.json` is missing or stale, ask: "Which 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-pages/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 `page-authoring` for type-scale and responsive rules before editing (bigger on desktop usually means a `sm:`/`lg:` step, not a fixed size).
+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.