create-ailk 0.6.1 → 0.8.0

package/templates/.claude/skills/add-schema/references/file-finding.md

@@ -1,123 +0,0 @@
-# File-Finding — Slug → File Resolution
-
-The `add-schema` skill resolves a slug like `/pricing` to one or
-more files in the consumer's repo. This file is the source of
-truth for the resolution logic the skill applies in Step 2.
-
-## The two locations to scan
-
-A slug can map to either (or both) of:
-
-1. **App Router route file.**
-   - Primary: `apps/web/app/<slug>/page.tsx` (monorepo layout, the
-     AILK default).
-   - Fallback: `app/<slug>/page.tsx` (standalone Next.js app at
-     repo root).
-   - Slug supports nested paths: `/products/widget` →
-     `app/products/widget/page.tsx`.
-   - The `[slug]` dynamic-route convention is also valid: `/blog/foo`
-     can map to `app/blog/[slug]/page.tsx`. The skill recognizes
-     both static and dynamic route files; for dynamic routes, it
-     modifies the route handler itself (not the dynamic instance).
-
-2. **MDX content file.**
-   - Scan: `content/**/<slug>.mdx`.
-   - The frontmatter `slug:` field is **authoritative** when
-     present. Filename match is a fallback.
-   - Multi-type content folders: a slug can live in
-     `content/Product/widget.mdx` or
-     `content/BlogPosting/widget.mdx`. The frontmatter `type:`
-     field disambiguates.
-
-## Match outcomes
-
-### Zero matches
-
-Refuse with a clear pointer:
-
-> "No page exists at `/<slug>`. Use `scaffold-page` (#362) to
-> create one first; come back here once it exists to add
-> additional schema."
-
-Do not write anything.
-
-### One match
-
-Proceed. Show the consumer which file you'll modify in Step 7's
-diff so they can confirm the path before any write.
-
-### Multiple matches
-
-List and ask. Common multi-match shapes:
-
-- **Route + MDX coexistence.** Many AILK pages have both a
-  `apps/web/app/<slug>/page.tsx` (renderer) and a
-  `content/<Type>/<slug>.mdx` (data). The route renders the MDX —
-  schema can attach in either:
-  - Attaching in the route puts JSON-LD in JSX.
-  - Attaching in the MDX puts JSON-LD inline in content.
-  - The canonical AILK pattern emits via the route (the route
-    imports `<JsonLd schema={builder(page)}/>` and reads frontmatter
-    via the content adapter). When in doubt, modify the route.
-
-- **Multiple MDX files for the same slug.** Rare; usually means
-  the consumer has organized content by `type/` and the same slug
-  appears in different type folders. List all matches with their
-  `type:` frontmatter and ask which one the consumer means.
-
-- **Static + dynamic route ambiguity.** If both `app/<slug>/page.tsx`
-  and `app/<slug>/[child]/page.tsx` exist, only the static
-  `<slug>/page.tsx` is the target — the dynamic file handles
-  child routes, not the index.
-
-Ask the consumer plainly:
-
-> "Found multiple files for `/<slug>`:
->
-> - `apps/web/app/<slug>/page.tsx` — App Router route
-> - `content/Product/<slug>.mdx` — MDX content
->
-> Where should I attach the schema? (Recommended: route, since
-> JSON-LD belongs in the rendered output.)"
-
-Wait for the consumer's choice.
-
-## What the skill does NOT touch
-
-- **Layout files.** `apps/web/app/layout.tsx` is the right place
-  for site-wide identity schema (`Organization` / `Person`). If
-  the consumer asks to add identity schema to a leaf page, the
-  skill flags this and asks (per `references/schema-types.md`).
-- **`globals.css`, `metadata.ts`, `route.ts`** — these aren't
-  where JSON-LD lives. The skill scans only `page.tsx` and
-  `*.mdx` for slug-pattern matches.
-- **`packages/schema/`** — read-only at v1 (per the issue scope).
-  The skill imports from `@working-theory/schema` but never modifies it.
-
-## Edge case — non-MDX content backend
-
-If the consumer's project uses a non-MDX adapter (Sanity, Payload,
-or any other), the MDX scan returns nothing. The skill still tries
-the App Router route file. If the route exists, attaching schema
-there works regardless of where the page's content data lives.
-
-If the consumer wants schema attached **to content** (not the
-route) and they're on a non-MDX backend, this skill at v1 says:
-
-> "Your content backend isn't MDX. JSON-LD attachment in
-> non-MDX backends ships in a future PR. For now, attach the
-> schema to the route file (`app/<slug>/page.tsx`) — that's
-> rendered server-side and works regardless of content adapter."
-
-## Validation after resolution
-
-Before any write, the skill confirms the resolved file is one of:
-
-- `.tsx` (App Router page) — must contain `export default
-function … Page()`.
-- `.mdx` (content file) — must have frontmatter delimiters
-  (`---`).
-
-If the file at the resolved path doesn't match one of those
-shapes, the skill surfaces the mismatch and stops. Don't write to
-a file you can't recognize.

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

@@ -1,234 +0,0 @@
-# Schema Types — Primary / Supplementary Catalog
-
-The schema.org types `add-schema` recognizes, each tagged
-**primary** (typically one per page) or **supplementary** (stacks
-freely). The skill reads this file to decide replace-vs-append in
-Step 6 of the mechanic.
-
-This catalog mirrors `@working-theory/schema`'s exports. When new builders
-ship in `@working-theory/schema`, this file updates in a follow-up PR. Until
-then, unrecognized types fall through to the "ask the consumer"
-path in SKILL.md.
-
-## Primary types (one per page; replace on conflict)
-
-These name what the page **is about**. Replacing on same-type
-conflict is the usual intent — adding a new `Product` schema
-generally means swapping the existing one.
-
-| `@type`             | Builder            | Aliases                       | Typical page              |
-| ------------------- | ------------------ | ----------------------------- | ------------------------- |
-| `HomePage`          | `buildHomePage`    | "home"                        | `/`                       |
-| `AboutPage`         | `buildAboutPage`   | "about"                       | `/about`                  |
-| `ContactPage`       | `buildContactPage` | "contact"                     | `/contact`                |
-| `PrivacyPage`       | `buildPrivacyPage` | "privacy"                     | `/privacy`                |
-| `TermsPage`         | `buildTermsPage`   | "terms"                       | `/terms`                  |
-| `Product`           | `buildProduct`     | "product"                     | Per-item product page     |
-| `Service`           | `buildService`     | "service", "service offering" | `/pricing`, `/services/*` |
-| `Article`           | `buildArticle`     | "article"                     | Editorial piece           |
-| `BlogPosting`       | `buildBlogPosting` | "blog post", "post"           | `/blog/<slug>`            |
-| `NewsArticle`       | `buildNewsArticle` | "news article"                | News piece                |
-| `Course`            | `buildCourse`      | "course"                      | `/courses/<slug>`         |
-| `Event`             | `buildEvent`       | "event"                       | Event landing             |
-| `JobPosting`        | `buildJobPosting`  | "job", "career"               | `/jobs/<slug>`            |
-| `Recipe`            | `buildRecipe`      | "recipe"                      | Per-recipe page           |
-| `Book`              | `buildBook`        | "book"                        | Book detail page          |
-| `Movie`             | `buildMovie`       | "movie", "film"               | Movie detail              |
-| `MusicAlbum`        | `buildMusicAlbum`  | "album"                       | Album page                |
-| `RealEstateListing` | _consumer-defined_ | "listing", "property"         | `/listings/<slug>`        |
-
-## Supplementary types (stack freely; always append)
-
-These add **dimensions** to a page that already has a primary
-type. Multiple of these can coexist on one page — never replace,
-always append.
-
-| `@type`           | Builder               | Aliases                       | Use                                   |
-| ----------------- | --------------------- | ----------------------------- | ------------------------------------- |
-| `FAQPage`         | _consumer-defined_    | "faq", "FAQ"                  | Q&A block on any page                 |
-| `HowTo`           | _consumer-defined_    | "how-to", "howto", "tutorial" | Step-by-step instructions             |
-| `BreadcrumbList`  | `buildBreadcrumbList` | "breadcrumbs"                 | Site navigation context               |
-| `Review`          | _consumer-defined_    | "review"                      | Single review (within Product, etc.)  |
-| `AggregateRating` | _consumer-defined_    | "rating", "ratings", "stars"  | Aggregate of reviews                  |
-| `VideoObject`     | _consumer-defined_    | "video"                       | Embedded video metadata               |
-| `ImageObject`     | _consumer-defined_    | "image"                       | Image with structured metadata        |
-| `AudioObject`     | _consumer-defined_    | "audio", "podcast"            | Audio embed metadata                  |
-| `Offer`           | _consumer-defined_    | "offer"                       | Pricing offer (under Product/Service) |
-| `OfferCatalog`    | _consumer-defined_    | "catalog", "offer catalog"    | Multi-offer container                 |
-| `MonetaryAmount`  | _consumer-defined_    | "monetary amount", "amount"   | Used inside Service / Offer           |
-
-## Identity types (one site-wide; emit on home or in layout)
-
-These are **the site's identity**. Typically one per site (not per
-page) and lives in the home page or a layout component. The skill
-treats them as **primary** for the conflict logic but flags the
-consumer if they're trying to add one to a non-home page.
-
-| `@type`         | Builder             | Aliases                          | Use                       |
-| --------------- | ------------------- | -------------------------------- | ------------------------- |
-| `Organization`  | `buildOrganization` | "org", "organization", "company" | Business identity         |
-| `Person`        | `buildPerson`       | "person", "individual"           | Solo individual identity  |
-| `LocalBusiness` | _consumer-defined_  | "local business"                 | Brick-and-mortar business |
-| `Restaurant`    | _consumer-defined_  | "restaurant"                     | Restaurant subtype        |
-| `Store`         | _consumer-defined_  | "store"                          | Retail subtype            |
-
-When adding `Organization` or `Person` to a non-home page, the
-skill should ask:
-
-> "`Organization` is typically a site-wide identity emitted in
-> the layout (so it appears on every page). Adding it to one
-> page means only that page surfaces the entity. Continue, or
-> add it to your layout instead?"
-
-## Specialty types
-
-Less-frequently-used but in the catalog. The skill recognizes
-these by name; conflict handling defaults to **supplementary**
-(append).
-
-| `@type`                             | Builder            | Aliases                          |
-| ----------------------------------- | ------------------ | -------------------------------- |
-| `MedicalCondition`                  | _consumer-defined_ | "medical condition"              |
-| `MedicalProcedure`                  | _consumer-defined_ | "medical procedure", "procedure" |
-| `Drug`                              | _consumer-defined_ | "drug", "medication"             |
-| `LearningResource`                  | _consumer-defined_ | "lesson", "learning resource"    |
-| `EducationalOccupationalCredential` | _consumer-defined_ | "credential", "certification"    |
-| `SoftwareApplication`               | _consumer-defined_ | "app", "software"                |
-| `MobileApplication`                 | _consumer-defined_ | "mobile app"                     |
-| `WebApplication`                    | _consumer-defined_ | "web app"                        |
-| `Dataset`                           | _consumer-defined_ | "dataset"                        |
-| `ScholarlyArticle`                  | _consumer-defined_ | "scholarly article", "paper"     |
-| `LegislativeBuilding`               | _consumer-defined_ | _rare, government use_           |
-
-## AILK page types (registry-backed — 60 keys, one builder each)
-
-Every key below is an entry in `@working-theory/schema`'s page-type registry
-(`packages/schema/src/registry/entries.ts`) and has a real, exported builder
-reachable via `buildJsonLd({ type: '<Key>', ... })` — this is the complete
-list of scaffoldable AILK page types, as opposed to the smaller general
-schema.org vocabulary tables above (some of which is still
-`_consumer-defined_`, i.e. not yet builder-backed). Several keys share one
-`@type` (e.g. `PrivacyPage` / `TermsPage` / `LandingPage` / `ThankYouPage` all
-emit `WebPage`) — the registry has 60 entries but only 24 distinct `@type`
-values. Re-derive with `pnpm page-type-counts`
-(`scripts/component/page-type-counts.ts` in the `ai-launch-kit-internal`
-source repo) before hand-editing this table.
-
-### Core (15)
-
-| Key | `@type` |
-| --- | --- |
-| `HomePage` | `HomePage` |
-| `AboutPage` | `AboutPage` |
-| `ContactPage` | `ContactPage` |
-| `PrivacyPage` | `WebPage` |
-| `TermsPage` | `WebPage` |
-| `LandingPage` | `WebPage` |
-| `ThankYouPage` | `WebPage` |
-| `BookCall` | `WebPage` |
-| `NewsletterSignup` | `WebPage` |
-| `DemoRequest` | `WebPage` |
-| `TrialSignup` | `WebPage` |
-| `Waitlist` | `WebPage` |
-| `Assessment` | `WebApplication` |
-| `Calculator` | `WebApplication` |
-| `CampaignLP` | `WebPage` |
-
-### Identity (4)
-
-`Organization` / `Person` / `BreadcrumbList` / `ContactPoint` — see the
-[Identity types](#identity-types-one-site-wide-emit-on-home-or-in-layout)
-table above; all four are registry-backed.
-
-### Canonical-List (17)
-
-| Key | `@type` |
-| --- | --- |
-| `ServicesList` | `CollectionPage` |
-| `ProductsList` | `CollectionPage` |
-| `ProjectsList` | `CollectionPage` |
-| `FAQPage` | `FAQPage` |
-| `CareersList` | `CollectionPage` |
-| `UseCasesList` | `CollectionPage` |
-| `TestimonialsList` | `CollectionPage` |
-| `ClientsList` | `CollectionPage` |
-| `DownloadsList` | `CollectionPage` |
-| `EventsList` | `CollectionPage` |
-| `CoursesList` | `CollectionPage` |
-| `TeamList` | `CollectionPage` |
-| `PartnersList` | `CollectionPage` |
-| `IntegrationsList` | `CollectionPage` |
-| `GlossaryList` | `CollectionPage` |
-| `LocationsList` | `CollectionPage` |
-| `DocsList` | `CollectionPage` |
-
-### Canonical-Detail (14)
-
-| Key | `@type` |
-| --- | --- |
-| `Service` | `Service` |
-| `Product` | `Product` |
-| `Project` | `CreativeWork` |
-| `Event` | `Event` |
-| `Course` | `Course` |
-| `TeamMember` | `ProfilePage` |
-| `Partner` | `AboutPage` |
-| `Integration` | `WebPage` |
-| `JobPosting` | `JobPosting` |
-| `SoftwareProduct` | `WebPage` |
-| `Location` | `Place` |
-| `ServiceAreaPage` | `WebPage` |
-| `UseCase` | `WebPage` |
-| `Pricing` | `WebPage` |
-
-### Editorial-List (3)
-
-| Key | `@type` |
-| --- | --- |
-| `BlogList` | `Blog` |
-| `ResourcesHub` | `CollectionPage` |
-| `CaseStudiesList` | `CollectionPage` |
-
-### Editorial-Detail (7)
-
-| Key | `@type` |
-| --- | --- |
-| `BlogPosting` | `BlogPosting` |
-| `CaseStudy` | `Article` |
-| `HowTo` | `HowTo` |
-| `Whitepaper` | `Article` |
-| `ResourceDetail` | `Article` |
-| `TechArticle` | `TechArticle` |
-| `DocsDetail` | `TechArticle` |
-
-## Total
-
-**Two distinct counts, not one.** The AILK page-type registry — the types
-`add-schema` can scaffold with a real builder — has **60 keys** (24 distinct
-`@type` values; see the family tables above). The general schema.org
-vocabulary tables earlier in this file are a separate, smaller, hand-curated
-list the skill also recognizes by name for non-registry types; several of
-those are still `_consumer-defined_` because `@working-theory/schema` hasn't
-shipped a typed builder for them yet — for those, the skill emits the JSON-LD
-as an inline literal with a comment noting the upstream issue.
-
-## When `@working-theory/schema` doesn't yet export the builder
-
-Some entries above say `_consumer-defined_` for the builder
-column. The skill's behavior in that case:
-
-1. Surface the gap:
-
-   > "`@working-theory/schema` doesn't export `build<Type>` yet. I can:
-   >
-   > - Emit the JSON-LD as an inline object literal (less
-   >   type-safe but works).
-   > - Skip — you author it manually using the canonical
-   >   `<JsonLd schema={...}/>` pattern.
-   >
-   > Which?"
-
-2. Wait for the consumer's choice. Don't fabricate a builder.
-
-This matches `scaffold-page` (#362)'s behavior — both skills handle
-the missing-builder case the same way.

package/templates/.claude/skills/provision-config/references/runbook-template.md

@@ -1,248 +0,0 @@
-# `RUNBOOK.md` Template
-
-The `provision-config` skill emits this runbook at the consumer's
-project root. It documents pre-deploy steps, the **critical**
-leads-persistence caveat, and the three named upgrade paths.
-
-The skill must verify all three named persistence-section headings
-are present after emit (per SKILL.md Step 6 validation). If any is
-missing, the skill has a bug.
-
-## Template
-
-```markdown
-# RUNBOOK — Production Operations
-
-This runbook is generated by the `provision-config` skill. It covers
-what to do before and after deploying to Vercel, plus the
-operational caveats AILK ships with.
-
-If you re-run `provision-config`, new sections may be appended at
-the end under "## Added by provision-config." Existing sections are
-not modified by the skill.
-
----
-
-## Pre-deploy checklist
-
-Before you click Deploy in Vercel:
-
-- [ ] **Add a Vercel project** pointed at this repo
-      (`vercel link` from the CLI, or the dashboard).
-- [ ] **Set environment variables** in Vercel's project dashboard
-      (Settings → Environment Variables). Use `.env.example` as the
-      contract — every variable listed there should have a value
-      set in Vercel before deploy.
-- [ ] **Configure your custom domain** if you have one (Vercel
-      Project → Settings → Domains). Vercel handles TLS automatically.
-- [ ] **Pick a leads-persistence backend** — see the three named
-      upgrade paths below. **Do not deploy without picking one** if
-      your site captures leads. AILK's default `leads.jsonl`
-      fallback does not persist on Vercel's ephemeral filesystem.
-- [ ] **Register production OAuth callbacks** if you used
-      `scaffold-auth` and activated Google or GitHub. Each provider
-      needs the prod callback URL added to its OAuth app settings.
-
----
-
-## Operations — leads.jsonl persistence
-
-> **Critical:** AILK's default lead-capture writes to
-> `apps/api/leads.jsonl`. On Vercel's ephemeral filesystem, this
-> file **does not persist** across cold starts. Leads captured
-> during one container's lifetime are lost when that container
-> shuts down.
-
-You **must** pick a persistence backend before going live or you
-will lose leads. Pick one of the three sections below based on
-your situation:
-
-- Cheapest fix, drop-in, native Vercel — **Vercel KV**
-- One provider for db + auth + storage — **Supabase**
-- Already have Postgres elsewhere — **Postgres via `@working-theory/database`**
-
----
-
-## Persistence upgrade — Vercel KV
-
-**When to pick:** you want the cheapest fix, no new infra, and
-you're already on Vercel. Vercel KV is Redis-compatible key-value
-storage, native to the Vercel dashboard.
-
-**Setup:**
-
-1. Vercel Dashboard → Storage → Create Database → KV.
-2. Connect to your project. Vercel auto-populates
-   `KV_REST_API_URL` and `KV_REST_API_TOKEN` in your project
-   environment.
-3. Pull updated env vars locally: `vercel env pull`.
-4. Switch the lead-capture writer in your code from JSONL to KV
-   (`@working-theory/api`'s lead-capture supports a KV adapter — see its
-   README for the wiring).
-5. Redeploy.
-
-**Trade-offs:** KV is fast and easy but has limits (storage
-ceilings, access patterns). For >10K leads/month or rich querying,
-graduate to Supabase or Postgres.
-
----
-
-## Persistence upgrade — Supabase
-
-**When to pick:** you want one provider for database, auth, and
-storage. You're not committed to NextAuth (Supabase has its own
-auth), or you're fine running NextAuth + Supabase auth in parallel.
-
-**Setup:**
-
-1. Sign up at <https://supabase.com>.
-2. Create a project.
-3. Go to Settings → API. Copy:
-   - `Project URL` → `NEXT_PUBLIC_SUPABASE_URL`
-   - `anon public` key → `NEXT_PUBLIC_SUPABASE_ANON_KEY`
-   - `service_role` key → `SUPABASE_SERVICE_ROLE_KEY` (server-only)
-4. Set those three env vars in Vercel project settings.
-5. Run the AILK Supabase migration (see `@working-theory/database` Supabase
-   adapter README — the migration creates a `leads` table with the
-   AILK schema).
-6. Switch the lead-capture writer to use the Supabase adapter.
-7. Redeploy.
-
-**Trade-offs:** Supabase is generous on free tier, scales well, and
-its dashboard is excellent. The auth coexistence with NextAuth is
-the only design wrinkle — most consumers either use NextAuth alone
-(treating Supabase as just a Postgres host) or commit to Supabase
-auth and remove NextAuth.
-
----
-
-## Persistence upgrade — Postgres via `@working-theory/database`
-
-**When to pick:** you already have Postgres somewhere — Neon,
-Railway, RDS, self-hosted, anywhere. You don't need a new provider
-relationship.
-
-**Setup:**
-
-1. Get a Postgres connection string from your provider. Format:
-   `postgres://user:password@host:5432/dbname`.
-2. Set `DATABASE_URL` in Vercel project settings.
-3. Install `@working-theory/database`: `pnpm add @working-theory/database`.
-4. Run the migration:
-   `pnpm --filter @working-theory/database run migrate:deploy` (or your
-   provider's equivalent).
-5. The `@working-theory/database` package exposes a Prisma client tied to the
-   AILK schema; switch the lead-capture writer to use it.
-6. Redeploy.
-
-**Trade-offs:** most flexible, most setup. You manage the database
-yourself (backups, connection pooling, scaling). For consumers who
-already have Postgres in their stack, this is the natural fit.
-
----
-
-## Custom domain + DNS
-
-Vercel handles TLS automatically once a domain is added to your
-project. Two paths:
-
-- **Vercel-managed DNS** — let Vercel handle nameservers. Easiest;
-  Vercel Dashboard → Project → Settings → Domains → Add → "Manage
-  DNS Records."
-- **External DNS** — add an A record (or CNAME for subdomains)
-  pointing at Vercel's IP, then add the domain to your project.
-  Vercel docs walk through it.
-
-For email-sending domains (Resend, magic-link), you'll also need
-to verify the sending domain in Resend's dashboard before
-production magic-link emails will deliver. Resend Dashboard →
-Domains → Add → DNS records → wait for verification.
-
----
-
-## Production callbacks for OAuth (if you used `scaffold-auth`)
-
-If you activated Google or GitHub OAuth via `scaffold-auth` (#364),
-those activations used dev callback URLs (`localhost:3000`). For
-production, add the prod callback URLs to each OAuth app:
-
-### Google
-
-1. Open the Google Cloud Console OAuth client you created
-   (<https://console.cloud.google.com/apis/credentials>).
-2. Under **Authorized redirect URIs**, add:
-   `https://<your-prod-domain>/api/auth/callback/google`
-3. Save.
-
-### GitHub
-
-1. Open the GitHub OAuth App you created
-   (<https://github.com/settings/developers>).
-2. Edit either:
-   - The same app's **Authorization callback URL** to add a second
-     line for prod (GitHub allows multiple).
-   - Or create a separate OAuth App for production.
-3. Update the env vars in Vercel if you created a separate app.
-
----
-
-## When to redeploy
-
-- After changing any `NEXT_PUBLIC_*` env var (those bake at build
-  time).
-- After running database migrations (data shape changed).
-- After updating `vercel.json` (deploy config changed).
-
-You do **not** need to redeploy after:
-
-- Adding a non-`NEXT_PUBLIC_*` env var in Vercel's dashboard
-  (server-side reads pick it up on next request).
-- Editing MDX content in `content/` and pushing — Vercel rebuilds
-  on push.
-
----
-
-## Troubleshooting
-
-- **"My leads disappeared"** → you skipped the leads-persistence
-  upgrade. Pick one of Vercel KV / Supabase / Postgres above and
-  migrate the writer.
-- **"OAuth login redirects to localhost in production"** → you
-  haven't added the production callback URL to the OAuth app
-  (see above).
-- **"Magic-link emails aren't arriving in production"** → your
-  Resend sender domain isn't verified yet (Resend Dashboard →
-  Domains).
-
----
-```
-
-## Section headings the validation must find
-
-After emit, the skill must grep for these three headings (verbatim
-match). All three must be present:
-
-- `## Persistence upgrade — Vercel KV`
-- `## Persistence upgrade — Supabase`
-- `## Persistence upgrade — Postgres via `@working-theory/database\``
-
-If any is missing, the template was edited in a way that broke the
-contract. Surface the failure to the consumer (not silent).
-
-## Merge logic
-
-If the consumer already has `RUNBOOK.md`, the skill (per SKILL.md
-Step 3) offers merge / overwrite / skip. Merge logic:
-
-1. Read the existing file.
-2. Check whether each of the three named persistence section
-   headings is already present.
-3. Headings already present → not modified.
-4. Headings missing → append at the end of the existing file under:
-   ```
-   ## Added by provision-config
-   ```
-
-The pre-deploy checklist, custom-domain, and OAuth-prod-callbacks
-sections are also appended if missing. Sections that are already
-present (even with different content) are not modified.