create-ailk 0.6.0 → 0.7.0

package/templates/.claude/skills/{scaffold-auth → add-auth}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: scaffold-auth
+name: add-auth
 description: Activate auth providers (magic-link via Resend, Google OAuth, GitHub OAuth) on an AILK consumer site. Use when the user says "wire up auth", "add login", "set up sign-in", "I need users to log in", or asks how to enable any of magic-link / Google / GitHub auth on their AILK site. The skill writes env vars for whichever subset of providers the consumer activates and prints (plus saves) an OAuth-app-setup runbook. It does NOT modify `auth.config.ts` and does NOT emit any pages.
 ---
 
-# scaffold-auth
+# add-auth
 
 Activate one or more auth providers on an AILK site by writing the env
 vars NextAuth reads to detect them, plus a `RUNBOOK.md` that documents
@@ -24,14 +24,14 @@ Google / GitHub OAuth. Phrases that should trigger this skill:
 Skip this skill when:
 
 - The user wants a `/login` or `/account` _page_ — those are pages, not
-  auth wiring. Use `scaffold-page` (#362) for that.
+  auth wiring. Use `add-page` for that.
 - The user is asking about a third-party provider that isn't in the
   AILK locked set (Apple, Microsoft, Twitter, etc.). The locked set is
   magic-link + Google + GitHub at v1; broader provider support is a
   future PR. Acknowledge the request and stop.
 - The user is in production and needs production callback URLs. v1
   ships dev-mode callbacks (`http://localhost:3000`) only —
-  production callback setup is deferred to `provision-config` (#367)
+  production callback setup is deferred to `setup-deploy`
   or a future deploy skill. Note this and stop.
 
 ## What this skill does (and does not do)
@@ -207,7 +207,7 @@ Print:
 - A reminder to set `AILK_AUTH_REQUIRED=1` in `.env.local` if they
   want protected routes (default is auth-disabled / public).
 - A pointer to `RUNBOOK.md` for future reference.
-- A pointer to `provision-config` (#367) for production callback URL
+- A pointer to `setup-deploy` for production callback URL
   setup when the consumer is ready to deploy.
 
 ## Re-invocation
@@ -252,9 +252,9 @@ This means the skill's job is purely env-var wiring + documentation.
 
 ## Coordination
 
-- **`scaffold-page` (#362)** — `/login` or `/account` pages. This skill
+- **`add-page`** — `/login` or `/account` pages. This skill
   emits no pages.
-- **`provision-config` (#367)** — production callback URL setup. v1
+- **`setup-deploy`** — production callback URL setup. v1
   is dev-only.
 - **`@working-theory/database`** — Prisma adapter detection. Install
   `@working-theory/database` separately to upgrade from JWT-only to persistent

package/templates/.claude/skills/{scaffold-auth → add-auth}/references/env-vars.md

@@ -1,7 +1,7 @@
 # Auth Env-Var Contract
 
 Source of truth for which env vars activate which auth provider on
-an AILK consumer site. Read by the `scaffold-auth` skill before
+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` →
@@ -32,7 +32,7 @@ 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).
 - `NEXTAUTH_URL` and `NEXTAUTH_SECRET` are deferred to production-time
-  setup (`provision-config` (#367) or future deploy skill).
+  setup (`setup-deploy` or future deploy skill).
 
 ## Env-var formats — what valid values look like
 

package/templates/.claude/skills/{scaffold-auth → add-auth}/references/oauth-app-setup.md

@@ -1,6 +1,6 @@
 # OAuth + Magic-Link Setup — RUNBOOK Template
 
-The `scaffold-auth` skill writes (or merges into) `RUNBOOK.md` at the
+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.
 
@@ -85,7 +85,7 @@ 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
-`provision-config` skill or your future deploy skill will help you
+`setup-deploy` skill or your future deploy skill will help you
 wire this when you're ready to ship.
 
 ### Rotating the client secret
@@ -133,7 +133,7 @@ GITHUB_CLIENT_SECRET=...
 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 `provision-config` skill or your future deploy skill will help
+The `setup-deploy` skill or your future deploy skill will help
 you wire this when you're ready to ship.
 
 ### Rotating the client secret

package/templates/.claude/skills/{scaffold-page → add-page}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: scaffold-page
-description: Generate a new page on an AILK consumer site — App Router route + MDX content stub + typed JSON-LD attachment — in a single confirm-before-write pass. Use when the user says "scaffold me a /pricing page", "add an about page", "create a /contact route", or chains a row from `suggest-site-pages` output (e.g., "scaffold home — Organization — anchor with hero, value prop, CTA"). Both invocation shapes flow through the same pipeline. MDX-only at v1; refuses on existing routes and points at `add-schema` (#366).
+name: add-page
+description: Generate a new page on an AILK consumer site — App Router route + MDX content stub + typed JSON-LD attachment — in a single confirm-before-write pass. Use when the user says "scaffold me a /pricing page", "add an about page", "create a /contact route", or hands over a structured triple (e.g., "add home — Organization — anchor with hero, value prop, CTA"). Both invocation shapes flow through the same pipeline. MDX-only at v1; refuses on existing routes and points at the `schema:` frontmatter override for adding structured data to a page that already exists.
 ---
 
-# scaffold-page
+# add-page
 
 Generate a new page in one pass. Three artifacts emit together:
 
@@ -20,31 +20,29 @@ The consumer wants a new page on their AILK site. Triggers:
 
 - "scaffold me a /pricing page" / "create a /contact route"
 - "add an about page" / "I need a /privacy page"
-- A row chained from `suggest-site-pages` output:
-  `home — Organization — anchor with hero, value prop, CTA`
-- "scaffold that one" referring to a specific row from prior chat output
+- A structured triple: `home — Organization — anchor with hero, value prop, CTA`
+- "add that one" referring to a specific row from prior chat output
 
 Skip this skill when:
 
-- The consumer wants to **add schema to an existing page** — that's
-  `add-schema` (#366). This skill refuses on existing routes and
-  points at #366 explicitly.
-- The consumer wants to **plan their pages** — that's
-  `suggest-site-pages` (#361). Output of #361 is this skill's chained
-  input contract.
+- The consumer wants to **add supplementary schema to an existing
+  page** — that's the `schema:` frontmatter override (see
+  [Adding schema to an existing page](#adding-schema-to-an-existing-page)
+  below), not a separate skill. This skill refuses on existing routes
+  and points there.
 - The consumer's content backend is **not MDX**. v1 is MDX-only —
   other adapters (Sanity, Payload, additional adapters) are additive
   future PRs. Refuse with a clear message.
 
 ## What this skill does
 
-1. Parses the consumer's input — chained format
+1. Parses the consumer's input — structured triple
    (`<slug> — <Schema.orgType> — <purpose>`) OR free-text.
 2. Resolves the **primary schema.org type** for the page using
-   `references/page-types.md` (about → AboutPage, pricing → Service,
+   `references/page-types.md` (about → AboutPage, pricing → Pricing,
    etc.). Confirms the choice before writing.
 3. Detects existing routes and refuses if `app/<slug>/page.tsx`
-   already exists, pointing at `add-schema` (#366).
+   already exists, pointing at the `schema:` frontmatter override.
 4. Detects content adapter — only MDX is supported at v1; refuses
    on any other adapter with a clear message.
 5. Emits three files via `templates/route.tsx.tmpl` and
@@ -52,12 +50,13 @@ Skip this skill when:
    typed builder import from `@working-theory/schema`.
 6. Shows the consumer a **single diff** of all three files and waits
    for one confirmation. After approval, writes all files.
-7. Closing summary: pointer at `add-schema` (#366) for additional
-   schema, pointer at `audit-site` (#365) for citation-readiness check.
+7. Closing summary: pointer at the `schema:` frontmatter override for
+   additional schema, pointer at `check-site` for citation-readiness check.
 
 ## What this skill does NOT do
 
-- Modify an existing route. Refuses + points at `add-schema` (#366).
+- Modify an existing route. Refuses + points at the `schema:`
+  frontmatter override.
 - Run `pnpm dev` or rebuild content. The consumer does that.
 - Detect content-adapter type beyond "is it MDX?". v1 ships MDX
   only; other adapters are out of scope.
@@ -74,12 +73,12 @@ Skip this skill when:
 
 The consumer's request can arrive in either shape:
 
-**Chained shape** (from `suggest-site-pages` output):
+**Structured triple:**
 
 ```
 home — Organization — anchor with hero, value prop, CTA
 about — AboutPage — company story and team
-pricing — Service — public price tiers and feature comparison
+pricing — Pricing — public price tiers and feature comparison
 ```
 
 Three em-dash-separated fields: `<slug>` `<Schema.orgType>` `<purpose>`.
@@ -113,7 +112,7 @@ backend?
 
 If neither exists, refuse:
 
-> "scaffold-page only supports the MDX content backend at v1. Your
+> "add-page only supports the MDX content backend at v1. Your
 > project doesn't appear to have one — file an issue at the upstream
 > repo if you'd like Sanity / Payload / additional adapter support."
 
@@ -126,10 +125,11 @@ depending on the consumer's structure).
 
 If it exists, refuse:
 
-> "A route at `/<slug>` already exists. To **add schema** to an
-> existing page, run `add-schema` (#366) instead. To **replace** the
-> page entirely, delete the existing files first and re-run this
-> skill."
+> "A route at `/<slug>` already exists. To **add structured data** to
+> an existing page, use the `schema:` frontmatter override (see this
+> skill's [Adding schema to an existing page](#adding-schema-to-an-existing-page)
+> section) instead. To **replace** the page entirely, delete the
+> existing files first and re-run this skill."
 
 Stop. No writes.
 
@@ -187,57 +187,71 @@ Print:
 - The two paths written.
 - Reminder: `pnpm dev` to see the page, `pnpm build` to confirm it
   compiles.
-- Pointer at `add-schema` (#366) for adding supplementary schema
-  (FAQPage, HowTo, Product, etc.) to this page later.
-- Pointer at `audit-site` (#365) for citation-readiness check after
+- Pointer at the `schema:` frontmatter override for adding
+  supplementary schema (FAQPage-shaped Q&A, a `Review`, a richer
+  `mainEntity`, etc.) to this page later.
+- Pointer at `check-site` for citation-readiness check after
   adding pages.
 
-## Cross-skill chaining
+## Adding schema to an existing page
 
-Output of `suggest-site-pages` (#361) is this skill's input contract.
-The consumer can paste any row of #361's output verbatim and this
-skill scaffolds it. Example end-to-end:
+There is no separate skill for this — a page's MDX frontmatter
+already carries an escape hatch. `page.schema` is a
+`Record<string, unknown>`, opaque to the typed builder, that the
+builder merges on top of its derived fields after deriving them
+(frontmatter wins on conflict). Use it to add structured sub-entities,
+enrich a page with additional fields, or override any derived field
+— without re-scaffolding the route.
 
-1. Consumer asks `suggest-site-pages` for a SaaS page list.
-2. Output includes: `pricing — Service — public price tiers and feature comparison`
-3. Consumer says: "scaffold that pricing one"
-4. This skill resolves the row, emits route + MDX + JSON-LD, all in
-   one confirm-before-write pass.
-5. Consumer continues with the next row, or moves on.
+```yaml
+# in an existing page's MDX frontmatter
+---
+type: BlogPosting
+slug: hello-world
+title: Hello, World
+description: First post.
+schema:
+  author:
+    "@type": Person
+    name: Jane Doe
+---
+```
 
-## What lives in `references/page-types.md`
+Where an override key lands depends on the builder's shape — a
+two-layer builder (a `WebPage`-family envelope wrapping a described
+`mainEntity`, e.g. `BlogPosting`, `Service`, `Product`, `JobPosting`)
+routes most keys to the entity and a known few to the envelope; every
+other builder shallow-merges `page.schema` onto the top level. The
+full routing table is `packages/schema/README.md` § `schema` field
+override — read it before guiding a consumer through a non-obvious
+placement (e.g. `mainEntity` object merges, `@type` retyping).
 
-The type-to-schema mapping is data, not logic. Read the references
-file at runtime — don't try to remember the table.
+This is also how a page picks up a **supplementary** schema type that
+has no builder of its own — an `Offer`, a `Review`, an `AggregateRating`
+— since those are expressed as plain objects inside `schema:`, not as
+a distinct AILK page type.
 
-The mapping covers the canonical AILK page types:
+## What lives in `references/page-types.md`
 
-- Identity — `home → HomePage`, `about → AboutPage`
-- Conversion — `pricing → Service`, `contact → ContactPage`
-- Trust — `privacy → PrivacyPage`, `terms → TermsPage`
-- Editorial — `blog → Blog`, `blog/<slug> → BlogPosting`
-- Catalog — `products → ItemList`, `products/<slug> → Product`
-- Q&A — `faq → FAQPage`, `how-to/<slug> → HowTo`
+The type-to-schema mapping is data, not logic. Read the references
+file at runtime — don't try to remember the table. It is generated
+from `packages/schema/src/registry/entries.ts` by
+`packages/create-ailk/scripts/generate-page-types-reference.ts` —
+never hand-edit it; regenerate it instead (`pnpm page-types:build` from
+`packages/create-ailk`) whenever a registry key changes.
 
-The full list is in `references/page-types.md`. New types added to
-`@working-theory/schema` should be added to that file in a follow-up PR; the
-skill renders unrecognized types as a "missing from page-types.md"
-prompt to ask the consumer rather than guessing.
+The mapping covers every registered AILK page type — family, chassis,
+schema.org `@type`, and the route convention — with list/detail pairs
+(e.g. `ServicesList` / `Service`) shown together.
 
 ## Coordination
 
-- **`suggest-site-pages` (#361)** — output is this skill's chained
-  input. The two skills' references corpora (`categories.md` and
-  `page-types.md`) must agree on schema-type names.
-- **`add-schema` (#366)** — modifies existing pages. The
-  `<JsonLd schema={build<Type>(...)} />` attachment pattern is
-  shared with this skill (canonical pattern landed in #389 /
-  `@working-theory/jsonld`).
-- **`audit-site` (#365)** — citation-readiness check. Runs after
+- **`check-site`** — citation-readiness check. Runs after
   pages exist; not invoked from inside this skill.
-- **`@working-theory/jsonld`** (#389) — the React component for JSON-LD
+- **`@working-theory/jsonld`** — the React component for JSON-LD
   rendering. Single source of truth for the attachment pattern.
 - **`@working-theory/schema`** — typed builders (`buildHomePage`,
-  `buildAboutPage`, etc.). The skill's emit imports from here.
+  `buildAboutPage`, etc.). The skill's emit imports from here, and its
+  README documents the `schema` frontmatter override in full.
 - **`@working-theory/content-adapters`** (MDX) — the content backend. v1 is
   MDX-only; other adapters are deferred.

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

@@ -0,0 +1,111 @@
+<!-- GENERATED — do not hand-edit. Regenerate with:
+       cd packages/create-ailk && pnpm page-types:build
+     Source: packages/schema/src/registry/entries.ts
+     Generator: packages/create-ailk/scripts/generate-page-types-reference.ts
+-->
+
+# 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
+`packages/schema/src/registry/entries.ts` — 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.
+
+`<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 `packages/schema/README.md` for the full
+override contract.
+
+## Core
+
+| Key | `@type` | Family | Chassis | Route |
+| --- | --- | --- | --- | --- |
+| `HomePage` | `HomePage` | core | home | / |
+| `AboutPage` | `AboutPage` | core | detail | /about |
+| `ContactPage` | `ContactPage` | core | detail | /contact |
+| `PrivacyPage` | `WebPage` | core | detail | /privacy |
+| `TermsPage` | `WebPage` | core | detail | /terms |
+| `PurchasePolicyPage` | `WebPage` | core | detail | /purchase-policy |
+| `WorkingAgreementPage` | `WebPage` | core | detail | /working-agreement |
+| `LandingPage` | `WebPage` | core | home | /<slug> |
+| `ThankYouPage` | `WebPage` | core | detail | /thanks/<slug> |
+| `BookCall` | `WebPage` | core | home | /book-a-call |
+| `NewsletterSignup` | `WebPage` | core | home | /newsletter |
+| `DemoRequest` | `WebPage` | core | home | /demo-request |
+| `TrialSignup` | `WebPage` | core | home | /trial-signup |
+| `Waitlist` | `WebPage` | core | home | /waitlist |
+| `Assessment` | `WebApplication` | core | home | /assessment |
+| `Calculator` | `WebApplication` | core | home | /calculator |
+| `CampaignLP` | `WebPage` | core | home | /<slug> |
+
+## Identity
+
+| Key | `@type` | Family | Chassis | Route |
+| --- | --- | --- | --- | --- |
+| `Organization` | `Organization` | identity | detail | — site-wide identity — emitted on the home page or in a layout |
+| `Person` | `Person` | identity | detail | — site-wide identity — emitted on the home page or in a layout |
+| `BreadcrumbList` | `BreadcrumbList` | identity | detail | — site-wide — attached alongside another page's own schema |
+| `ContactPoint` | `ContactPoint` | identity | detail | — site-wide — embedded in `Organization` or `Person` |
+
+## Canonical
+
+| Key | `@type` | Family | Chassis | Route |
+| --- | --- | --- | --- | --- |
+| `ServicesList` | `CollectionPage` | canonical-list | list | /services |
+| `Service` | `Service` | canonical-detail | detail | /services/<slug> |
+| `ProductsList` | `CollectionPage` | canonical-list | list | /products |
+| `Product` | `Product` | canonical-detail | detail | /products/<slug> |
+| `ProjectsList` | `CollectionPage` | canonical-list | list | /projects |
+| `Project` | `CreativeWork` | canonical-detail | detail | /projects/<slug> |
+| `FAQPage` | `FAQPage` | canonical-list | list | /faq |
+| `CareersList` | `CollectionPage` | canonical-list | list | /careers |
+| `JobPosting` | `JobPosting` | canonical-detail | detail | /careers/<slug> |
+| `UseCasesList` | `CollectionPage` | canonical-list | list | /use-cases |
+| `UseCase` | `WebPage` | canonical-detail | detail | /use-cases/<slug> |
+| `TestimonialsList` | `CollectionPage` | canonical-list | list | /testimonials |
+| `ClientsList` | `CollectionPage` | canonical-list | list | /clients |
+| `DownloadsList` | `CollectionPage` | canonical-list | list | /downloads |
+| `EventsList` | `CollectionPage` | canonical-list | list | /events |
+| `Event` | `Event` | canonical-detail | detail | /events/<slug> |
+| `CoursesList` | `CollectionPage` | canonical-list | list | /courses |
+| `Course` | `Course` | canonical-detail | detail | /courses/<slug> |
+| `TeamList` | `CollectionPage` | canonical-list | list | /team |
+| `TeamMember` | `ProfilePage` | canonical-detail | detail | /team/<slug> |
+| `PartnersList` | `CollectionPage` | canonical-list | list | /partners |
+| `Partner` | `AboutPage` | canonical-detail | detail | /partners/<slug> |
+| `IntegrationsList` | `CollectionPage` | canonical-list | list | /integrations |
+| `Integration` | `WebPage` | canonical-detail | detail | /integrations/<slug> |
+| `GlossaryList` | `CollectionPage` | canonical-list | list | /glossary |
+| `LocationsList` | `CollectionPage` | canonical-list | list | /locations |
+| `Location` | `Place` | canonical-detail | detail | /locations/<slug> |
+| `DocsList` | `CollectionPage` | canonical-list | list | /docs |
+| `SoftwareProduct` | `WebPage` | canonical-detail | detail | /software/<slug> |
+| `ServiceAreaPage` | `WebPage` | canonical-detail | detail | /service-areas/<slug> |
+| `Pricing` | `WebPage` | canonical-detail | detail | /pricing |
+| `ComparisonPage` | `WebPage` | canonical-detail | detail | /comparisons/<slug> |
+| `ReportPage` | `Report` | canonical-detail | detail | /reports/<slug> |
+
+## Editorial
+
+| Key | `@type` | Family | Chassis | Route |
+| --- | --- | --- | --- | --- |
+| `BlogList` | `Blog` | editorial-list | list | /blog |
+| `BlogPosting` | `BlogPosting` | editorial-detail | detail | /blog/<slug> |
+| `ResourcesHub` | `CollectionPage` | editorial-list | list | /resources |
+| `ResourceDetail` | `Article` | editorial-detail | detail | /resources/<slug> |
+| `CaseStudiesList` | `CollectionPage` | editorial-list | list | /case-studies |
+| `CaseStudy` | `Article` | editorial-detail | detail | /case-studies/<slug> |
+| `HowTo` | `HowTo` | editorial-detail | detail | /how-to/<slug> |
+| `Whitepaper` | `Article` | editorial-detail | detail | /whitepapers/<slug> |
+| `TechArticle` | `TechArticle` | editorial-detail | detail | /tech-articles/<slug> |
+| `DocsDetail` | `TechArticle` | editorial-detail | detail | /docs/<slug> |

package/templates/.claude/skills/{scaffold-page → add-page}/templates/content.mdx.tmpl

@@ -10,7 +10,7 @@ description: {{DESCRIPTION}}
 {{DESCRIPTION}}
 
 <!--
-  This is the MDX content stub emitted by `scaffold-page`.
+  This is the MDX content stub emitted by `add-page`.
   The frontmatter is the source of truth for JSON-LD — the
   `{{BUILDER}}(page)` call in `app/{{SLUG}}/page.tsx` reads it.
 
@@ -21,8 +21,8 @@ description: {{DESCRIPTION}}
    - Don't change `type` unless you also update the route's import
      to match a different `@working-theory/schema` builder.
 
-  When you're happy with the page, run `audit-site` (#365) to see
-  how it scores on citation-readiness. Use `add-schema` (#366) to
-  add supplementary schema (FAQPage, HowTo, etc.) without
+  When you're happy with the page, run `check-site` to see
+  how it scores on citation-readiness. Use the `schema:` frontmatter
+  override to add supplementary schema (FAQPage, HowTo, etc.) without
   re-scaffolding.
 -->

package/templates/.claude/skills/{scaffold-page → add-page}/templates/route.tsx.tmpl

@@ -1,4 +1,4 @@
-// Emitted by `scaffold-page` at `app/{{SLUG}}/page.tsx`. Substitutions:
+// Emitted by `add-page` at `app/{{SLUG}}/page.tsx`. Substitutions:
 //   {{SLUG}}     — page slug (e.g., "pricing")
 //   {{TYPE}}     — schema.org @type (e.g., "Service")
 //   {{BUILDER}}  — typed builder name (e.g., "buildService")

package/templates/.claude/skills/{audit-site → check-site}/SKILL.md

@@ -1,14 +1,14 @@
 ---
-name: audit-site
+name: check-site
 description: Run `ailk-audit --json` on the consumer's AILK site, parse the JSON report, and explain the score and findings in plain language. Use when the user asks "how is my site doing?", "audit my site", "what's my score?", "is my JSON-LD valid?", "do I have all the schema I need?", or otherwise wants a citation-readiness check on their AILK content. The skill never edits files — it reports and points at fix tools.
 ---
 
-# audit-site
+# check-site
 
 Shell out to `ailk-audit --json`, parse the JSON, and turn it into a
 conversational summary the consumer can act on. Pure explain-only —
-the skill names fix tools (like `add-schema`) but does not invoke
-them.
+the skill names fix tools (like the `schema:` frontmatter override)
+but does not invoke them.
 
 ## When to use
 
@@ -24,7 +24,7 @@ citation-readiness audit (AEO Layer 1). Triggers:
 Skip this skill when:
 
 - The consumer wants to _fix_ a finding — point them at the fix
-  tool (usually `add-schema` (#366)) and stop. This skill reports;
+  tool (usually `add-page`'s `schema:` frontmatter override) and stop. This skill reports;
   fix tools fix.
 - The consumer is asking about deploy-time monitoring or continuous
   audits — those are Pro features (`ailk pro` for details). Mention
@@ -131,18 +131,17 @@ themselves on a subsequent turn.
 
 | Rule                  | Fix tool                                                                                 |
 | --------------------- | ---------------------------------------------------------------------------------------- |
-| `schema-coverage`     | `add-schema` (#366) — add the missing schema type to the named page                      |
-| `jsonld-validity`     | `add-schema` (#366) — replace the invalid block; or hand-fix the MDX                     |
+| `schema-coverage`     | `add-page`'s `schema:` frontmatter override — add the missing schema type to the named page |
+| `jsonld-validity`     | `add-page`'s `schema:` frontmatter override — replace the invalid block; or hand-fix the MDX |
 | `entity-markup`       | Manual edit — ensure `Organization` (or `Person`) JSON-LD is emitted somewhere site-wide |
-| `faq-howto-incentive` | `add-schema` (#366) — add an `FAQPage` or `HowTo` block to a relevant page               |
+| `faq-howto-incentive` | `add-page`'s `schema:` frontmatter override — add an `FAQPage` or `HowTo` block to a relevant page |
 
 Phrase the pointer as a single sentence:
 
-> "Missing `Product` schema on `/pricing` — run `add-schema` (#366)
-> to add it."
+> "Missing `Product` schema on `/pricing` — add it via `add-page`'s
+> `schema:` frontmatter override."
 
-Never invoke `add-schema` automatically. Never write to the
-consumer's repo from inside this skill.
+Never write to the consumer's repo from inside this skill.
 
 ### Step 8 — Soft Pro mention
 
@@ -187,8 +186,8 @@ Never recommend "weekly" / "monthly" / a date.
 ## What this skill does NOT do
 
 - Edit any file in the consumer's repo.
-- Add JSON-LD to pages (that's `add-schema` #366).
-- Create new pages (that's `scaffold-page` #362).
+- Add JSON-LD to pages (that's the `schema:` frontmatter override, documented in `add-page`).
+- Create new pages (that's `add-page`).
 - Cache results between runs.
 - Track score history or trends.
 - Auto-invoke fix tools.
@@ -202,9 +201,9 @@ Never recommend "weekly" / "monthly" / a date.
 
 ## Coordination
 
-- **`add-schema` (#366)** — primary fix tool the skill points at.
-  Never auto-invoked.
-- **`scaffold-page` (#362)** — new-page creation; not a fix-tool
+- **`add-page`'s `schema:` frontmatter override** — primary fix
+  mechanism the skill points at. Never auto-invoked.
+- **`add-page`** — new-page creation; not a fix-tool
   for audit findings (audit reports on existing pages).
 - **`packages/aeo`** — owner of the `ailk-audit` CLI and rule set.
   This skill depends only on the CLI's `--json` output schema, not

package/templates/.claude/skills/{audit-site → check-site}/references/common-errors.md

@@ -1,7 +1,7 @@
 # Common Errors — Plain-Language Translations
 
 The three most common ways `ailk-audit` fails on a real consumer
-setup, with translations the `audit-site` skill emits instead of
+setup, with translations the `check-site` skill emits instead of
 the raw stderr. Errors not matching any of these signatures pass
 through verbatim with a one-line `` `ailk-audit` failed — `` prefix
 (see SKILL.md Step 2).
@@ -56,8 +56,8 @@ mis-translate an unfamiliar error into a familiar fix path.
 >
 > - Your content lives elsewhere — pass `--content-root <path>`
 >   to point at the right directory.
-> - You haven't authored any pages yet — run `suggest-site-pages`
->   to plan your pages, then `scaffold-page` to generate them.
+> - You haven't authored any pages yet — run `add-page` to generate
+>   them.
 > - The MDX files exist but aren't in the format the AILK content
 >   adapter expects — make sure each page has frontmatter with at
 >   least `title` and `type`.

package/templates/.claude/skills/{audit-site → check-site}/references/findings-glossary.md

@@ -2,7 +2,7 @@
 
 What each AEO rule means in plain language, what its `pass: false`
 result indicates, and what the consumer can do about it. Used by the
-`audit-site` skill in Step 6 (drill-down) and Step 7 (fix-tool
+`check-site` skill in Step 6 (drill-down) and Step 7 (fix-tool
 pointer).
 
 The structure deliberately matches `perRule[].id` from the audit
@@ -30,9 +30,10 @@ SGE, Perplexity, ChatGPT search) read to understand your pages. A
 page with no schema is invisible to citation; a page with the
 wrong schema gets miscategorized.
 
-**Fix tool:** `add-schema` (#366) — invoke it with the page slug
-and the schema type the registry expects (the audit names both).
-The skill will emit a `<JsonLd>` block matching the page's content.
+**Fix tool:** `add-page`'s `schema:` frontmatter override — set the
+schema type the registry expects (the audit names it) on the page's
+frontmatter. The typed builder emits a `<JsonLd>` block matching the
+page's content.
 
 ---
 
@@ -52,10 +53,10 @@ invalid blocks. The page exists, the JSON-LD exists, but the
 citation surface is broken because the block doesn't parse as
 valid schema.org.
 
-**Fix tool:** `add-schema` (#366) — replace the malformed block.
-For one-off edits to MDX, the consumer can also hand-edit the
-JSON-LD inline; `add-schema` is the safer path because it uses
-typed builders.
+**Fix tool:** `add-page`'s `schema:` frontmatter override — replace
+the malformed block. For one-off edits to MDX, the consumer can also
+hand-edit the JSON-LD inline; the frontmatter override is the safer
+path because it uses typed builders.
 
 ---
 
@@ -81,8 +82,9 @@ have nothing to anchor to.
 layout component rendered on every page) emits an
 `Organization` (or `Person`) JSON-LD block. The `<JsonLd
 schema={OrganizationSchema(...)} />` pattern from `@working-theory/schema`
-is the one this is going to ship as. `add-schema` (#366) can land
-the block on a specific page if you'd rather; but typically
+is the one this is going to ship as. `add-page`'s `schema:`
+frontmatter override can land the block on a specific page if you'd
+rather; but typically
 identity goes in a layout, not a leaf page.
 
 ---
@@ -105,10 +107,10 @@ explicit Q&A or step-by-step content because those are easier to
 quote directly into a generated response. Adding an FAQ or HowTo
 block to relevant pages is a low-effort score boost.
 
-**Fix tool:** `add-schema` (#366) — add an `FAQPage` block to
-your `/pricing` or `/contact` page (anywhere your customers ask
-predictable questions), or a `HowTo` block to any
-process/instructions content. `audit-site` will surface this as
+**Fix tool:** `add-page`'s `schema:` frontmatter override — add an
+`FAQPage` block to your `/pricing` or `/contact` page (anywhere your
+customers ask predictable questions), or a `HowTo` block to any
+process/instructions content. `check-site` will surface this as
 an _incentive_ in drill-down, not a finding to "fix."
 
 ---

package/templates/.claude/skills/{audit-site → check-site}/references/severity-levels.md

@@ -1,7 +1,7 @@
 # Severity Levels — Score Banding + Severity Mapping
 
 The AEO audit JSON does **not** include explicit severity fields.
-Severity is **derived** by the `audit-site` skill from each rule's
+Severity is **derived** by the `check-site` skill from each rule's
 `weight` and `pass`. This file is the source of truth for that
 mapping.