create-ailk 0.10.0 → 0.11.0

package/templates/.claude/skills/add-auth/references/env-vars.md

@@ -1,106 +0,0 @@
-# Auth Env-Var Contract
-
-Source of truth for which env vars activate which auth provider on
-an AILK consumer site. Read by the `add-auth` skill before
-asking the consumer to paste secrets.
-
-The activation logic lives in `apps/web/lib/auth-env.ts` →
-`getActiveProviderIds()`. A provider is active **only when every
-required var is set to a non-empty value**. Partial wiring (e.g.,
-`GOOGLE_CLIENT_ID` set but `GOOGLE_CLIENT_SECRET` missing) is treated
-as inactive — `apps/web/auth.ts` never constructs that provider.
-
-The site's auth library is **Better Auth** (`apps/web/auth.ts`,
-`betterAuth({ secret, baseURL, socialProviders, … })`).
-
-## Provider activation table
-
-| Provider ID | Required env vars                            | Source                       |
-| ----------- | -------------------------------------------- | ---------------------------- |
-| `email`     | `AUTH_EMAIL_SERVER` + `AUTH_EMAIL_FROM`      | Email sign-in (Resend)¹      |
-| `google`    | `GOOGLE_CLIENT_ID` + `GOOGLE_CLIENT_SECRET`  | Google OAuth                 |
-| `github`    | `GITHUB_CLIENT_ID` + `GITHUB_CLIENT_SECRET`  | GitHub OAuth                 |
-
-¹ Better Auth core ships no magic-link provider, so `email` is an
-env-presence signal: it switches on the password method
-(`emailAndPassword`) in `apps/web/auth.ts`, not a wired magic link.
-
-## Auxiliary auth env vars
-
-| Var                    | Default | Effect                                                                                |
-| ---------------------- | ------- | ------------------------------------------------------------------------------------- |
-| `AILK_AUTH_REQUIRED`   | unset   | Read by `isAuthRequired()` in `apps/web/lib/auth-env.ts` (`"1"` or `"true"`). Default is auth-disabled / public, so a fresh scaffold boots without requiring any auth wiring. |
-| `BETTER_AUTH_URL`      | unset   | The site's public origin (e.g. `https://your-domain.com`). Better Auth builds OAuth callback URLs on it and it is the one trusted origin; unset, Better Auth derives both from each request. Set it in production. Local dev can leave it unset. |
-| `BETTER_AUTH_SECRET`   | unset   | Signs session cookies and email-verification tokens. **Required in production** — `apps/web/auth.ts` throws when it is unset there, rather than fall back to the development secret published in the source. Generate with `openssl rand -base64 32`. Optional for `next dev`. |
-| `AILK_AUTH_SIGNUP_OPEN` | unset | Read by `isSignUpOpen()` in `apps/web/lib/auth-env.ts` (`"1"` or `"true"`). Unset, public sign-up is closed: with `email` active, the password form signs existing accounts in but creates none. |
-| `AILK_AUTH_PASSWORD_RESET` | unset | Read by `isResetAvailable()` (`"1"` or `"true"`). Password reset also needs `BETTER_AUTH_URL`, `BETTER_AUTH_SECRET` and `AUTH_EMAIL_WEBHOOK_SECRET` (`resetSendConfigured()`). |
-| `AUTH_EMAIL_WEBHOOK_SECRET` | unset | Signs the auth-mail relay from `apps/web` to `apps/api`, which sends with `RESEND_API_KEY` from `AUTH_EMAIL_FROM`. Set the same value for both apps; unset, no auth mail is sent. |
-
-The skill writes none of these auxiliary vars unasked. It mentions
-them in the closing summary so the consumer is aware:
-
-- `AILK_AUTH_REQUIRED` is the consumer's call (skill always defaults
-  to leaving it unset).
-- `AILK_AUTH_SIGNUP_OPEN` is the consumer's call too; the skill asks
-  when `email` is active, because with sign-up closed and no OAuth
-  provider nobody can create the first account.
-- `AILK_AUTH_PASSWORD_RESET` and `AUTH_EMAIL_WEBHOOK_SECRET` are the
-  auth-mail setup the `email` sub-flow describes.
-- `BETTER_AUTH_URL` and `BETTER_AUTH_SECRET` are deferred to
-  production-time setup (`setup-deploy`), and a production deploy
-  fails without `BETTER_AUTH_SECRET`.
-
-## Env-var formats — what valid values look like
-
-### `AUTH_EMAIL_SERVER` (email sign-in via Resend)
-
-```
-smtp://resend:<RESEND_API_KEY>@smtp.resend.com:465
-```
-
-The Resend API key starts with `re_`. The literal username is the
-string `resend` (Resend's SMTP convention). Port 465 is implicit-TLS
-SMTP.
-
-### `AUTH_EMAIL_FROM` (email sign-in via Resend)
-
-A verified sender address on the consumer's Resend account. For
-development, `onboarding@resend.dev` works without verification.
-
-### `GOOGLE_CLIENT_ID` / `GITHUB_CLIENT_ID`
-
-Public identifiers issued by Google / GitHub. Typically:
-
-- Google: ends in `.apps.googleusercontent.com`
-- GitHub: 20-character hex string
-
-Either can be safely committed to a public template; production
-secrets stay in `.env.local`.
-
-### `GOOGLE_CLIENT_SECRET` / `GITHUB_CLIENT_SECRET`
-
-Sensitive values. Treat as passwords. Never commit. The skill writes
-these only to `.env.local` (which is in the consumer scaffold's
-`.gitignore` by default).
-
-## Detection of "already activated"
-
-The skill's Step 1 menu marks providers as `[x]` when both required
-vars are set in `.env.local`. The detection is presence-only — the
-skill does not validate that the values actually work (no Google
-API ping, no GitHub API ping, no test SMTP connection). A consumer
-who pasted typos will get a runtime auth error from Better Auth on
-their first sign-in attempt; the fix is to re-run the skill and
-overwrite.
-
-## Where these vars are read
-
-- `apps/web/lib/auth-env.ts` — `getActiveProviderIds()` and
-  `isAuthRequired()`.
-- `apps/web/auth.ts` — `buildSocialProviders()` consumes the
-  active-provider list and builds Better Auth's `socialProviders`
-  from the matching env vars; `resolveSecret()` reads
-  `BETTER_AUTH_SECRET`, and `baseURL` is `BETTER_AUTH_URL`.
-
-The skill never modifies any of those files. All activation is
-env-var-driven.

package/templates/.claude/skills/add-auth/references/oauth-app-setup.md

@@ -1,180 +0,0 @@
-# OAuth + Email Sign-In Setup — RUNBOOK Template
-
-The `add-auth` skill writes (or merges into) `RUNBOOK.md` at the
-consumer's repo root using the per-provider sections below. Only the
-sections for providers actually activated this session are emitted.
-
-The skill **substitutes nothing** in these blocks at runtime — they're
-copy-paste ready as-is. The only per-session variation is which
-sections appear in the final runbook.
-
----
-
-## Provider section: email (Resend)
-
-```markdown
-## Auth — email sign-in (Resend)
-
-Email-and-password sign-in is activated when both env vars are present
-in `.env.local`:
-
-- `AUTH_EMAIL_SERVER` — `smtp://resend:<API_KEY>@smtp.resend.com:465`
-- `AUTH_EMAIL_FROM` — verified sender address on your Resend account
-
-### One-time setup
-
-1. Sign up at <https://resend.com> (free tier is fine for development).
-2. Create an API key: <https://resend.com/api-keys>. Save it
-   somewhere safe — you'll only see it once.
-3. Use a verified sender. For development, `onboarding@resend.dev` is
-   Resend's shared dev sender and works without verification. For
-   production, verify your own sending domain in the Resend dashboard.
-
-`AUTH_EMAIL_SERVER` is read for its presence only. The auth mail
-(verification, password reset) is sent by `apps/api` with
-`RESEND_API_KEY` from `AUTH_EMAIL_FROM`, so set both for the API, and
-set `AUTH_EMAIL_WEBHOOK_SECRET` to the same random value for both apps.
-
-Public sign-up stays closed until you set `AILK_AUTH_SIGNUP_OPEN=1` in
-`.env.local`.
-
-### `.env.local` entries
-
-\`\`\`
-AUTH_EMAIL_SERVER=smtp://resend:re_yourapikeyhere@smtp.resend.com:465
-AUTH_EMAIL_FROM=onboarding@resend.dev
-\`\`\`
-
-### Rotating the API key
-
-If you rotate the Resend API key, update `AUTH_EMAIL_SERVER` in
-`.env.local` and restart the dev server.
-```
-
----
-
-## Provider section: Google OAuth
-
-```markdown
-## Auth — Google OAuth
-
-Google sign-in is activated when both env vars are present in
-`.env.local`:
-
-- `GOOGLE_CLIENT_ID`
-- `GOOGLE_CLIENT_SECRET`
-
-### One-time setup
-
-1. Open <https://console.cloud.google.com/apis/credentials>.
-2. If you haven't yet, configure the OAuth consent screen:
-   - User type: **External** (unless you're inside a Workspace org).
-   - Fill in app name, support email, and developer contact email.
-   - Scopes are requested by Better Auth at runtime — leave the
-     consent screen scope list empty.
-3. Click **Create Credentials → OAuth client ID**.
-4. Application type: **Web application**.
-5. Name: anything (e.g., "AILK dev").
-6. **Authorized redirect URIs** — add exactly:
-   `http://localhost:3000/api/auth/callback/google`
-7. Click **Create**. Copy the Client ID and Client secret from the
-   dialog (you can return to copy them later via the Credentials page).
-
-### `.env.local` entries
-
-\`\`\`
-GOOGLE_CLIENT_ID=...
-GOOGLE_CLIENT_SECRET=...
-\`\`\`
-
-### Production callback URL
-
-The `localhost` callback above is dev-only. For production, you'll
-need to add a second redirect URI to the same OAuth client (or
-create a separate prod client) of the form
-`https://<your-prod-domain>/api/auth/callback/google`. The
-`setup-deploy` skill or your future deploy skill will help you
-wire this when you're ready to ship.
-
-### Rotating the client secret
-
-In the Google Console, find the OAuth client, generate a new secret,
-update `GOOGLE_CLIENT_SECRET` in `.env.local`, and restart the dev
-server. The Client ID stays the same.
-```
-
----
-
-## Provider section: GitHub OAuth
-
-```markdown
-## Auth — GitHub OAuth
-
-GitHub sign-in is activated when both env vars are present in
-`.env.local`:
-
-- `GITHUB_CLIENT_ID`
-- `GITHUB_CLIENT_SECRET`
-
-### One-time setup
-
-1. Open <https://github.com/settings/developers>.
-2. Click **New OAuth App**.
-3. Application name: anything (e.g., "AILK dev").
-4. Homepage URL: `http://localhost:3000`
-5. **Authorization callback URL** — add exactly:
-   `http://localhost:3000/api/auth/callback/github`
-6. Click **Register application**.
-7. On the resulting app page, click **Generate a new client secret**
-   and copy it immediately (GitHub shows it once).
-8. Copy the Client ID from the same page.
-
-### `.env.local` entries
-
-\`\`\`
-GITHUB_CLIENT_ID=...
-GITHUB_CLIENT_SECRET=...
-\`\`\`
-
-### Production callback URL
-
-The `localhost` callback above is dev-only. For production, either
-register a separate OAuth App with a `https://<your-prod-domain>/...`
-callback, or update this app's callback (GitHub allows multiple).
-The `setup-deploy` skill or your future deploy skill will help
-you wire this when you're ready to ship.
-
-### Rotating the client secret
-
-Generate a new client secret on the app's GitHub page, update
-`GITHUB_CLIENT_SECRET` in `.env.local`, and restart the dev server.
-The Client ID stays the same.
-```
-
----
-
-## Closing section (always emitted at the end of the runbook)
-
-```markdown
-## Activation summary
-
-| Provider    | Env vars                                          | Active |
-| ----------- | ------------------------------------------------- | ------ |
-| email       | `AUTH_EMAIL_SERVER` + `AUTH_EMAIL_FROM`           | <fill> |
-| Google      | `GOOGLE_CLIENT_ID` + `GOOGLE_CLIENT_SECRET`       | <fill> |
-| GitHub      | `GITHUB_CLIENT_ID` + `GITHUB_CLIENT_SECRET`       | <fill> |
-
-A provider is **active** when both required env vars are set in
-`.env.local`. The provider list is computed at server startup from env
-vars only (`getActiveProviderIds()` in `apps/web/lib/auth-env.ts`) — there
-are no `apps/web/auth.ts` edits to make.
-
-To require sign-in for protected routes, set in `.env.local`:
-
-\`\`\`
-AILK_AUTH_REQUIRED=1
-\`\`\`
-
-Default (unset or `0`) is auth-disabled / public — useful while
-building.
-```

package/templates/.claude/skills/add-page/SKILL.md

@@ -1,260 +0,0 @@
----
-name: add-page
-description: Add a new page to this AI Launch Kit site — a new service, a new "who it's for" page, a new booking page, a comparison against a competitor, a stand-alone landing page, or a whole route the site doesn't carry yet like /pricing — with its content file, its structured data and its nav link, in one confirm-before-write pass. Use this whenever the user wants a page that doesn't exist yet, even if they don't say "page" — "add a service for kitchen remodels", "I need a /pricing page", "make a page for dentists", "add a comparison with Acme", "we need a booking page for on-site estimates", "add a landing page for the spring offer", or a structured triple like "pricing — Pricing — plans and FAQ". Not for changing a page that already exists (fill-page writes content; update-page renames).
----
-
-# add-page
-
-Add a page this site can actually serve, at the path its routes really use,
-with a nav link, and nothing else. One plan, one confirmation, then write.
-
-The single most important fact about this site: **almost every page type
-already has its route.** Routes live in `apps/web/app/[locale]/…` and render
-whatever content file sits in `content/en/<Type>/`. So adding a page is
-usually **adding one content file**, not writing route code. Route code is
-only ever added by the `create-ailk add-route` command, never by hand — a
-hand-written route drifts from the template the site is built from and
-breaks the next `create-ailk` upgrade.
-
-## Step 1 — Read what this site can serve
-
-Run, from the site's root:
-
-```bash
-node .claude/skills/add-page/scripts/site-pages.mjs
-```
-
-It prints the site's shape, design and level (from `.ailk-site-manifest.json`),
-then one row per page type this site renders: its route, whether it takes new
-pages (a route with a `[slug]` does; a fixed route like `/about` is one page),
-and the pages already written. Add `--json` if you want to parse it.
-
-Treat this output as the truth about the site. `references/page-types.md`
-lists every page type AI Launch Kit knows — the vocabulary — but many of them
-are not on this site. Never offer a page type the script doesn't list unless
-you are also going to add its route (Step 3, case D).
-
-Then read `.ailk-site-manifest.json` at the site root yourself, the site's
-roster of record:
-
-- `modules` — the modules this site has. Add any module the `# Modules:`
-  line of `architecture.yaml` names that `modules` does not: `create-ailk
-  add-module` records a module it adds there. With no manifest, or none
-  carrying `modules`, that line is the set.
-- `rows` — every route the site already has (`route`) and the page type
-  each renders (`pageType`).
-- `level` — present only when the scaffold derived it from the licence key.
-  It never decides what to offer; `modules` does.
-
-A page type renders on this site only when the **Module** column of
-`references/page-types.md` names a module in that set. Never offer,
-suggest or write any other page type: a type whose Module the site lacks is
-case E, never case D.
-
-## Step 2 — Work out which page type the user wants
-
-The user may give a structured triple (`<slug> — <Type> — <purpose>`) or plain
-words. Resolve plain words to a type with `references/page-types.md`: an exact
-slug match first (`pricing` → `Pricing`), then a prefix (`services/…` →
-`Service`), then the purpose ("company story" → `AboutPage`). If two types
-fit, or none does, ask — a wrong type gives the page the wrong structured
-data, which is what search and answer engines read.
-
-Also settle the slug: lowercase, hyphenated, from the user's words
-(`kitchen-remodels`, not `kitchen_remodels` or `KitchenRemodels`).
-
-## Step 3 — Decide which case this is
-
-Check case C first: if the page the user describes already exists (the type is on a fixed route and its one page is in the "existing" column, or the slug is taken), stop there — nothing else in this skill applies.
-
-| Case | When | What you'll write |
-|---|---|---|
-| **A. New page on an existing route** | The type is listed and takes new pages (`Service`, `UseCase`, `PortfolioItem`, `BookCall`, `ThankYouPage`, …) | One content file: `content/en/<Type>/<slug>.mdx`. Plus a nav link if the page belongs in the nav. |
-| **B. Stand-alone landing page** | A one-off page at `/<slug>` that isn't any specific type (an offer, a campaign) | One content file: `content/en/LandingPage/<slug>.mdx`. The site's catch-all route serves it. |
-| **C. The page already exists** | A fixed-route type already has its page (`/about`, `/contact`, `/faq`), or `<slug>` is taken | Nothing. Say so. To change its words, use `fill-page`; to rename it or move its URL, use `update-page`. |
-| **D. The route isn't on this site** | The type exists in `page-types.md` but not in the script's output (e.g. `/pricing` on a person-service site) | First the route: `pnpm create ailk@latest add-route <route-id>` (run in the site root). `<route-id>` is the route family's name as `pnpm create ailk@latest --help` lists it under `--surfaces` — usually the first path segment (`pricing`, `alternatives`, `careers`). Then continue as case A (or case C for a fixed route — `add-route` seeds its page). |
-| **E. Needs a module the site doesn't have** | The type's **Module** in `page-types.md` is not in the site's modules (Step 1), or `add-route` refuses, naming a module (e.g. docs, blog, scheduling-backed booking) | Nothing yet. Tell the user which module renders it and which level carries it (the **Level** column), and point at the `upgrade-plan` skill. Don't try to recreate the module's routes by hand. |
-
-Why case B uses `LandingPage` rather than a new route: a route directory is
-template code the site inherits and upgrades; a content file is the owner's.
-Keeping one-off pages as content keeps upgrades clean.
-
-Comparison pages (`/vs/<competitor>`, listed on `/alternatives`) are case A on
-the `alternatives` route family, or case D when the site doesn't carry it yet
-(`add-route alternatives`). The `/alternatives` hub lists every comparison
-automatically — never hand-list them on the hub's page.
-
-Reports and flow landing pages are content on routes the **signal-collectors
-module** owns — see "Reports" and "Flow landing pages" below.
-
-## Step 4 — Draft the content file
-
-Copy the shape of a page the site already has **of the same type** — pick one
-from the "existing" column (e.g. `content/en/Service/first-engagement.mdx`).
-Its frontmatter is exactly what that type's route and structured-data builder
-expect, so matching it is how the new page renders and emits valid JSON-LD.
-Keep the same keys and section structure; replace the words.
-
-- Pick the page to copy with care: if the only page of this type is an odd one
-  (a hub slug, a stub), start from `templates/content.mdx.tmpl` instead and
-  borrow the section shapes from `content/en/HomePage/home.mdx`.
-- Set `slug` to the new slug and write a real `title` and `description` from
-  what the user said. `description` becomes the meta description and feeds the
-  structured data, so make it a true one-sentence summary.
-- Use the site's own name from `content/_site.mdx` wherever the page names
-  the business (a comparison's "us" side, a CTA) — don't leave `{Your Name}`
-  when the answer is on disk.
-- A time-limited offer carries its end date in structured data
-  (`schema: { offers: { validThrough: "2027-05-31" } }`) and says it in the
-  copy, so the page doesn't keep advertising an expired deal.
-- Where you don't have the owner's facts (prices, names, results), write
-  clearly-marked placeholder copy — never invent facts about their business.
-  Offer `fill-page` afterwards to write it properly.
-- If no page of this type exists yet, start from `templates/content.mdx.tmpl`
-  (or `templates/comparison-page.mdx.tmpl` for a comparison) and fill in the
-  `type` from `page-types.md`. Reports and flow landing pages have their own
-  templates — see their sections below.
-- Extra structured data (an `Offer`, a `Review`, an `author`) goes in the
-  frontmatter `schema:` block — see "Adding schema to a page" below. Don't
-  hand-write JSON-LD anywhere.
-
-## Step 5 — Link the page from its hub and the nav
-
-**The hub page.** Detail types sit under a list page: `Service` under
-`ServicesList` (`/services`), `UseCase` under `UseCasesList` (`/for`),
-`PortfolioItem` under `PortfolioList` (`/portfolio`). Open the hub's content
-file. If it lists its entries by hand (an `items` section with one entry per
-page, each with an `href`), add an entry for the new page in the same shape —
-otherwise visitors can't find it. The comparisons hub (`/alternatives`) and the
-reports hub (`/reports`) are the exceptions: they list their pages automatically.
-
-**The nav.**
-
-The site nav is `apps/web/lib/nav-config.ts`; its labels are keys in the
-`nav` section of `apps/web/messages/<locale>.json` (one file per language
-under `apps/web/messages/`).
-
-- A detail page under a list (a new service, a new persona) usually belongs in
-  that list's flyout or group in `nav-config.ts`. A stand-alone landing page
-  usually doesn't belong in the nav at all — ask if unsure. If it isn't in the
-  nav or a hub, tell the user how visitors will reach it (a link from the home
-  page, an email, an ad), because nothing on the site points to it yet.
-- Name a new `labelKey` after the page in camelCase (`kitchenRemodels`), not
-  after its position (`service4`), so it still makes sense after reordering.
-- A flyout may list the same links twice — once in `features` (the compact
-  view) and once in `groups` (the grouped view). Add the link to both.
-- To add a link: add an entry with the new `labelKey` and the locale-free path
-  (`/services/kitchen-remodels`, not `/en/…`), and add that key with its label
-  to **every** messages file (a site with one language has one file). A key
-  missing from one language breaks that language's nav.
-- Know the trade-off and tell the user once: `create-ailk` regenerates the nav
-  when a route or module is added, but only while `nav-config.ts` is exactly as
-  generated. Once hand-edited, later `add-route`/`add-module` runs leave it
-  alone and print the change they wanted instead.
-
-## Step 6 — Show the plan, confirm once, write
-
-Show every file you will create or change — the content file in full, and the
-exact lines added to the hub page, `nav-config.ts` and each messages file — plus any
-`add-route` command you'll run first. Wait for one confirmation. Then run the
-command (if any) and write the files. Don't write anything before the user
-confirms, and don't touch any other file.
-
-## Step 7 — Check it
-
-Run `pnpm build` from the site root. Then tell the user:
-
-- the new page's URL (with the locale, e.g. `/en/services/kitchen-remodels`)
-- that `fill-page` can write its real copy, and `check-site` can score it
-  for search and answer-engine readiness.
-
-If the build fails, the usual cause is frontmatter that doesn't match the
-type — compare the new file with the page you copied in Step 4.
-
-## Reports
-
-`ReportPage` (the `/reports/<slug>` report reader) is a hub-and-spoke family
-listed on the `/reports` hub (`ReportsList`). Its routes are
-**module-owned code** (the signal-collectors module's own
-`app/[locale]/reports/[slug]/page.tsx` and `app/[locale]/reports/page.tsx`),
-so this skill writes report **content only**, never report route code
-(spec 6892 D5).
-
-When the resolved type is `ReportPage` — a structured triple naming it, or
-free text like "add a report on Q3 results" — do this instead of Steps 3–4:
-
-1. Refuse when `app/[locale]/reports/[slug]/page.tsx` is absent, naming the
-   `signal-collectors` module: "This site has no report reader yet — run
-   `create-ailk add-module signal-collectors` first."
-2. Write `content/en/ReportPage/<slug>.mdx` from
-   `templates/report-page.mdx.tmpl` (substituting `{{SLUG}}`, `{{TITLE}}`,
-   `{{DESCRIPTION}}`, `{{DATE_PUBLISHED}}` — an ISO date — and
-   `{{DATE_LABEL}}` — the display string, e.g. "March 2025"). Refuse only
-   when that file already exists.
-3. When `content/en/ReportsList/reports.mdx` is absent, write it from
-   `templates/reports-list.mdx.tmpl` (substituting `{{TITLE}}`/`{{DESCRIPTION}}`
-   for the hub's own copy).
-
-The hub's own card list is **generated at request time** from whichever
-`ReportPage` seeds exist (`app/[locale]/reports/page.tsx` injects them) —
-never hand-list reports on the hub's MDX. Steps 5–7 apply as usual.
-
-## Flow landing pages
-
-A flow landing page is a single, standalone `LandingPage` whose CTA opens a
-named flow at `/flows/<slug>/start` — the referral-request shape (spec 6892
-D3). It belongs to no hub, but like the report family its route is
-**module-owned code** (the signal-collectors module's own
-`app/[locale]/flows/[slug]/start/page.tsx`), so this skill writes content
-only.
-
-When the consumer asks for a flow landing page — "add a referral page",
-"add a landing page for the intake flow" — given a flow slug:
-
-1. Refuse when `app/[locale]/flows/[slug]/start/page.tsx` is absent, naming
-   the `signal-collectors` module: "This site has no flow engine yet — run
-   `create-ailk add-module signal-collectors` first."
-2. Refuse when `content/en/LandingPage/<slug>.mdx` already exists — this
-   is a single standalone page, not a family member with its own detail
-   route.
-3. Write `content/en/LandingPage/<slug>.mdx` from
-   `templates/flow-landing-page.mdx.tmpl`, substituting `{{SLUG}}`,
-   `{{TITLE}}`, `{{DESCRIPTION}}` as usual and `{{FLOW_SLUG}}` — the flow's
-   own slug, which may differ from the page's `{{SLUG}}`.
-
-This skill writes no flow definition (`database/flows/<slug>.flow.json`) —
-that is a separate artifact, seeded through the flow engine, not through a
-page.
-
-## Adding schema to a page
-
-Every page's frontmatter has an escape hatch, `schema:`, that the page's
-structured-data builder merges on top of what it derives (frontmatter wins).
-Use it to add sub-entities or enrich fields, on a new page or an existing one:
-
-```yaml
----
-type: Service
-slug: kitchen-remodels
-title: Kitchen remodels
-description: Full kitchen remodels, from design to final inspection.
-schema:
-  offers:
-    "@type": Offer
-    priceCurrency: USD
-    price: "15000"
----
-```
-
-On types that wrap a described entity in a page (`Service`, `Product`,
-`BlogPosting`, `JobPosting`), most keys land on the entity; on others they
-merge at the top level. This is also how a page gets a supplementary type
-with no page type of its own — `Offer`, `Review`, `AggregateRating`.
-
-## What this skill does not do
-
-- Write or copy route code by hand — `create-ailk add-route` does that.
-- Change an existing page's words (`fill-page`), name or URL (`update-page`).
-- Add a module or change the site's level (`upgrade-plan` explains; the
-  owner decides).
-- Edit `_site.mdx`, the design, or another page's content.

package/templates/.claude/skills/add-page/references/page-types.md

@@ -1,123 +0,0 @@
-<!-- GENERATED — do not hand-edit. AI Launch Kit generates this file
-     from its page-type registry and ships it with the scaffold. The
-     source of record for this site's own page-type registry is `pageTypeRegistry` in the installed `@working-theory/schema` package.
--->
-
-# Page-Type → schema.org Registry Reference
-
-The full page-type catalog the `add-page` skill reads at runtime to
-resolve a slug or page-purpose hint to a family, chassis, schema.org
-`@type`, and route convention. Generated from the page-type registry
-`@working-theory/schema` exports — every registered page type appears
-exactly once, list/detail pairs are shown together, and no row here
-can name a type the registry doesn't have.
-
-The skill resolves in this order:
-
-1. **Exact slug match** — `pricing` → `Pricing`.
-2. **Slug-prefix match** — `blog/<anything>` → `BlogPosting`.
-3. **Free-text hint match** — "company story" / "team" → `AboutPage`.
-4. **Ask** — if nothing matches, ask the consumer rather than guessing.
-
-**Level** and **Module** name what a page type needs: the module whose
-code renders it, and the level that module comes with. Read the site's
-`.ailk-site-manifest.json` `modules` first — a page type whose Module is
-not in that list is one this site cannot render, so it is never offered;
-name its module and level instead (the `upgrade-plan` skill explains the
-levels). The level is the module's, never a claim about this site's key.
-
-`<slug>` in a route below is the page's own slug (e.g. `hello-world`);
-`<Type>` families using two-layer builders route supplementary schema
-through the `schema:` frontmatter override — see this skill's
-[Adding schema to an existing page](../SKILL.md#adding-schema-to-an-existing-page) section, or the installed `@working-theory/schema`
-package's README for the full override contract.
-
-## Core
-
-| Key | `@type` | Family | Chassis | Route | Level | Module |
-| --- | --- | --- | --- | --- | --- | --- |
-| `HomePage` | `HomePage` | core | home | / | Free | `marketing` |
-| `AboutPage` | `AboutPage` | core | detail | /about | Free | `marketing` |
-| `ContactPage` | `ContactPage` | core | detail | /contact | Free | `marketing` |
-| `PrivacyPage` | `WebPage` | core | detail | /privacy | Free | `marketing` |
-| `TermsPage` | `WebPage` | core | detail | /terms | Free | `marketing` |
-| `PurchasePolicyPage` | `WebPage` | core | detail | /purchase-policy | Free | `marketing` |
-| `WorkingAgreementPage` | `WebPage` | core | detail | /working-agreement | Free | `marketing` |
-| `LandingPage` | `WebPage` | core | home | /<slug> | Free | `marketing` |
-| `ThankYouPage` | `WebPage` | core | detail | /thanks/<slug> | Free | `marketing` |
-| `BookCall` | `WebPage` | core | home | /meet/:slug | Pro | `scheduling` |
-| `NewsletterSignup` | `WebPage` | core | home | /newsletter | Free | `marketing` |
-| `DemoRequest` | `WebPage` | core | home | /demo-request | Free | `marketing` |
-| `TrialSignup` | `WebPage` | core | home | /trial-signup | Free | `marketing` |
-| `Waitlist` | `WebPage` | core | home | /waitlist | Free | `marketing` |
-| `Assessment` | `WebApplication` | core | home | /assessment | Pro | `signal-collectors` |
-| `Calculator` | `WebApplication` | core | home | /calculator | Pro | `signal-collectors` |
-| `CampaignLP` | `WebPage` | core | home | /<slug> | Free | `marketing` |
-
-## Identity
-
-| Key | `@type` | Family | Chassis | Route | Level | Module |
-| --- | --- | --- | --- | --- | --- | --- |
-| `Organization` | `Organization` | identity | detail | — site-wide identity — emitted on the home page or in a layout | Free | `marketing` |
-| `Person` | `Person` | identity | detail | — site-wide identity — emitted on the home page or in a layout | Free | `marketing` |
-| `BreadcrumbList` | `BreadcrumbList` | identity | detail | — site-wide — attached alongside another page's own schema | Free | `marketing` |
-| `ContactPoint` | `ContactPoint` | identity | detail | — site-wide — embedded in `Organization` or `Person` | Free | `marketing` |
-
-## Canonical
-
-| Key | `@type` | Family | Chassis | Route | Level | Module |
-| --- | --- | --- | --- | --- | --- | --- |
-| `ServicesList` | `CollectionPage` | canonical-list | list | /services | Free | `marketing` |
-| `Service` | `Service` | canonical-detail | detail | /services/<slug> | Free | `marketing` |
-| `ProductsList` | `CollectionPage` | canonical-list | list | /products | Free | `marketing` |
-| `Product` | `Product` | canonical-detail | detail | /products/<slug> | Free | `marketing` |
-| `ProjectsList` | `CollectionPage` | canonical-list | list | /projects | Free | `marketing` |
-| `Project` | `CreativeWork` | canonical-detail | detail | /projects/<slug> | Free | `marketing` |
-| `FAQPage` | `FAQPage` | canonical-list | list | /faq | Free | `marketing` |
-| `CareersList` | `CollectionPage` | canonical-list | list | /careers | Free | `marketing` |
-| `JobPosting` | `JobPosting` | canonical-detail | detail | /careers/<slug> | Free | `marketing` |
-| `UseCasesList` | `CollectionPage` | canonical-list | list | /for | Free | `marketing` |
-| `UseCase` | `WebPage` | canonical-detail | detail | /for/<slug> | Free | `marketing` |
-| `PortfolioList` | `CollectionPage` | canonical-list | list | /portfolio | Free | `marketing` |
-| `PortfolioItem` | `WebPage` | canonical-detail | detail | /portfolio/<slug> | Free | `marketing` |
-| `FeaturesList` | `CollectionPage` | canonical-list | list | /features | Free | `marketing` |
-| `Feature` | `WebPage` | canonical-detail | detail | /features/<slug> | Free | `marketing` |
-| `ComparisonsList` | `CollectionPage` | canonical-list | list | /alternatives | Free | `marketing` |
-| `ComparisonPage` | `WebPage` | canonical-detail | detail | /vs/<slug> | Free | `marketing` |
-| `ReportsList` | `CollectionPage` | canonical-list | list | /reports | Free | `marketing` |
-| `ReportPage` | `Report` | canonical-detail | detail | /reports/<slug> | Pro | `signal-collectors` |
-| `TestimonialsList` | `CollectionPage` | canonical-list | list | /testimonials | Free | `marketing` |
-| `ClientsList` | `CollectionPage` | canonical-list | list | /clients | Free | `marketing` |
-| `DownloadsList` | `CollectionPage` | canonical-list | list | /downloads | Free | `marketing` |
-| `EventsList` | `CollectionPage` | canonical-list | list | /events | Free | `marketing` |
-| `Event` | `Event` | canonical-detail | detail | /events/<slug> | Free | `marketing` |
-| `CoursesList` | `CollectionPage` | canonical-list | list | /courses | Free | `marketing` |
-| `Course` | `Course` | canonical-detail | detail | /courses/<slug> | Free | `marketing` |
-| `TeamList` | `CollectionPage` | canonical-list | list | /team | Free | `marketing` |
-| `TeamMember` | `ProfilePage` | canonical-detail | detail | /team/<slug> | Free | `marketing` |
-| `PartnersList` | `CollectionPage` | canonical-list | list | /partners | Free | `marketing` |
-| `Partner` | `AboutPage` | canonical-detail | detail | /partners/<slug> | Free | `marketing` |
-| `IntegrationsList` | `CollectionPage` | canonical-list | list | /integrations | Free | `marketing` |
-| `Integration` | `WebPage` | canonical-detail | detail | /integrations/<slug> | Free | `marketing` |
-| `GlossaryList` | `CollectionPage` | canonical-list | list | /glossary | Free | `marketing` |
-| `LocationsList` | `CollectionPage` | canonical-list | list | /locations | Free | `marketing` |
-| `Location` | `Place` | canonical-detail | detail | /locations/<slug> | Free | `marketing` |
-| `DocsList` | `CollectionPage` | canonical-list | list | /docs | Pro | `docs-blog` |
-| `SoftwareProduct` | `WebPage` | canonical-detail | detail | /software/<slug> | Free | `marketing` |
-| `ServiceAreaPage` | `WebPage` | canonical-detail | detail | /service-areas/<slug> | Free | `marketing` |
-| `Pricing` | `WebPage` | canonical-detail | detail | /pricing | Free | `marketing` |
-
-## Editorial
-
-| Key | `@type` | Family | Chassis | Route | Level | Module |
-| --- | --- | --- | --- | --- | --- | --- |
-| `BlogList` | `Blog` | editorial-list | list | /blog | Free | `marketing` |
-| `BlogPosting` | `BlogPosting` | editorial-detail | detail | /blog/<slug> | Pro | `docs-blog` |
-| `ResourcesHub` | `CollectionPage` | editorial-list | list | /resources | Free | `marketing` |
-| `ResourceDetail` | `Article` | editorial-detail | detail | /resources/<slug> | Free | `marketing` |
-| `CaseStudiesList` | `CollectionPage` | editorial-list | list | /case-studies | Free | `marketing` |
-| `CaseStudy` | `Article` | editorial-detail | detail | /case-studies/<slug> | Free | `marketing` |
-| `HowTo` | `HowTo` | editorial-detail | detail | /how-to/<slug> | Free | `marketing` |
-| `Whitepaper` | `Article` | editorial-detail | detail | /whitepapers/<slug> | Free | `marketing` |
-| `TechArticle` | `TechArticle` | editorial-detail | detail | /tech-articles/<slug> | Free | `marketing` |
-| `DocsDetail` | `TechArticle` | editorial-detail | detail | /docs/<slug> | Pro | `docs-blog` |