create-ailk 0.9.0 → 0.11.0

package/templates/.claude/skills/setup-deploy/SKILL.md

@@ -1,275 +0,0 @@
----
-name: setup-deploy
-description: Emit deploy configuration for an AILK consumer site — `vercel.json`, `.env.example`, and `RUNBOOK.md`. Vercel-only at v1; other platforms reject with a clear "not yet supported" message. Use when the user asks "set up Vercel", "provision deploy config", "what env vars do I need for production?", "I'm ready to ship to Vercel", or otherwise asks about pre-deploy file setup. Asks where leads should go — the email key (`RESEND_API_KEY` + the two notification addresses) or a database (`setup-database`) — and warns when neither is set. The RUNBOOK documents the two lead destinations: Email (default) and Lead inbox (setup-database).
----
-
-# setup-deploy
-
-Emit `vercel.json`, `.env.example`, and `RUNBOOK.md` at the consumer's
-project root, ready for a Vercel deploy. Vercel is the only valid
-`platform` value at v1. Other platforms (Netlify, Cloudflare, Render,
-Fly, self-host) reject with an explicit "not yet supported" message
-and emit nothing.
-
-## When to use
-
-The consumer is preparing to deploy their AILK site for the first
-time, or wants to verify their deploy config is complete. Triggers:
-
-- "provision Vercel config" / "set up Vercel"
-- "what env vars do I need to deploy?"
-- "I'm ready to ship — what files do I need?"
-- "regenerate `vercel.json`" / "refresh `.env.example`"
-
-Skip this skill when:
-
-- The consumer is on a non-Vercel platform — emit the rejection
-  message (see Step 1) and stop.
-- The consumer asks about runtime environment values
-  (`process.env.X` debugging) — that's an app-level concern, not a
-  config-emission concern.
-- The consumer is asking about Stripe live-mode setup — that's
-  hard-floor blocked across AILK; sandbox-only at v1. Mention and stop.
-
-## What this skill does (and does not do)
-
-**Does:**
-
-- Validate the `platform` parameter — only `vercel` is accepted at v1.
-- Detect existing `vercel.json`, `.env.example`, and `RUNBOOK.md` at
-  the consumer's project root.
-- For each artifact, ask the consumer how to handle conflicts
-  (merge / overwrite / skip) before writing.
-- Emit the three artifacts at the consumer's project root, derived
-  from templates in `references/`.
-- Ask where leads go (Step 5a) — the email key, or a database via
-  `setup-database` — and warn, verbatim, when neither is set.
-- Validate the emitted output (parse `vercel.json` as JSON, check
-  `.env.example` covers required vars, confirm `RUNBOOK.md` has the
-  two lead-destination headings).
-
-**Does not:**
-
-- Call any Vercel API. The consumer runs `vercel deploy` themselves.
-- Read or write live secrets. `.env.example` uses placeholder values
-  only.
-- Configure Cloudflare anything (deploy target, KV, D1, R2). CF is
-  deferred entirely as a coherent follow-up unit.
-- Emit Netlify / Render / Fly / self-host config. v1 is Vercel only.
-- Modify the consumer's actual `.env.local` or any other file
-  containing real secrets.
-
-## The mechanic
-
-### Step 1 — Validate the platform parameter
-
-Default platform is `vercel`. If the consumer asks for any other
-platform, respond:
-
-> "`setup-deploy` is Vercel-only at v1. Netlify / Cloudflare /
-> Render / Fly / self-host support are tracked at the upstream repo —
-> file an issue at <https://github.com/working-theory-labs/ai-launch-kit/issues>
-> if your platform is missing.
->
-> Cloudflare is deferred entirely (deploy target + KV/D1/R2 data
-> layer) as a coherent follow-up."
-
-Then stop. Do not emit any files.
-
-### Step 2 — Detect existing artifacts
-
-Look for `vercel.json`, `.env.example`, and `RUNBOOK.md` at the
-consumer's project root. For each one, note:
-
-- **Missing** — will emit fresh.
-- **Present** — ask how to handle (Step 3).
-
-### Step 3 — Conflict handling per file
-
-For each existing artifact, show the consumer:
-
-1. The first ~10 lines of the existing file (preview).
-2. A summary of what the skill would emit (template name + key
-   fields).
-3. Three options: **merge** (only for `RUNBOOK.md` and
-   `.env.example` — see merge logic below), **overwrite**
-   (replace contents), **skip** (leave existing file untouched).
-
-Wait for the consumer's choice per file. Do not blindly overwrite.
-
-**Merge logic — `.env.example`:** if a var listed in
-`references/env-vars-template.md` is **missing** from the existing
-file, append it (with comment) at the bottom under a "## Added by
-setup-deploy" section. Vars already present are not modified.
-
-**Merge logic — `RUNBOOK.md`:** if the "Leads — where messages go"
-section (with its two headings, `Email (default)` and
-`Lead inbox (setup-database)`) is missing from the existing file,
-append it at the end. Existing sections are not modified.
-
-**Merge logic — `vercel.json`:** **not supported.** `vercel.json` is
-either overwritten or skipped — no field-level merge. Reason: the
-file is small and consumers are likely to have customized it
-intentionally; merging risks subtle config drift.
-
-### Step 4 — Emit `vercel.json`
-
-Use the template at `references/vercel-json-template.md`. The
-emitted file has these fields:
-
-- `version: 2` — Vercel config schema version.
-- `framework: "nextjs"` — Vercel auto-detects `apps/web` as Next.js.
-- `buildCommand` — pnpm-aware build (typically
-  `cd ../.. && pnpm install --frozen-lockfile && pnpm --filter ./apps/web build`
-  for monorepo deploys, or `pnpm build` for single-app deploys).
-- `installCommand` — match the consumer's package manager.
-- `env` — env-var passthrough; AILK ships an empty `env: {}` and
-  expects Vercel's project-level env-var dashboard to handle real
-  values.
-
-After write, parse the JSON. If parse fails, the skill has a bug —
-report it to the consumer with the literal error.
-
-### Step 5 — Emit `.env.example`
-
-Use the template at `references/env-vars-template.md`. The emitted
-file lists every env var the consumer's site reads, grouped by
-concern (auth, content, payments, analytics, etc.) with placeholder
-values and inline comments.
-
-The skill **does not** read live `.env` files. Placeholder values
-only. No `sk_live_*`, no `pk_live_*`, no real Resend keys, no real
-NextAuth secrets.
-
-After write, count the declared vars and confirm the count matches
-the template's expected count. If a var the consumer's site uses
-(grep `process.env.X` from a quick scan) is missing from the
-template, add it under "## Added by setup-deploy" — never silently
-omit a var the consumer needs.
-
-### Step 5a — Lead delivery
-
-Where a contact-form message goes is decided by the API project's
-environment (RUNBOOK § "Leads — where messages go"). Ask the consumer
-two questions:
-
-1. **Will this site use a database?** If yes, point them to the
-   `setup-database` skill — it provisions Postgres, sets
-   `DATABASE_URL`, runs migrations and verifies a test lead reaches
-   the inbox. Do not collect a connection string here.
-2. **What email should messages go to?** Ask for
-   `RESEND_API_KEY`, `AILK_LEAD_NOTIFICATION_TO` (their address) and
-   `AILK_LEAD_NOTIFICATION_FROM` (a sender on their Resend-verified
-   domain). All three are needed — a key alone sends nothing. Write
-   **placeholders only** into `.env.example`; tell the consumer to set
-   the real values in the **API** project's dashboard. Never write a
-   key into a file.
-
-If the consumer provides neither a database nor all three email
-values, print this, verbatim:
-
-> ⚠ No lead destination is set. In production your contact page will show
-> your contact email instead of the form, and no messages will be collected.
-> Run setup-database, or set RESEND_API_KEY, AILK_LEAD_NOTIFICATION_TO and
-> AILK_LEAD_NOTIFICATION_FROM on the API project.
-
-Then continue — the warning does not stop the deploy config.
-
-### Step 6 — Emit `RUNBOOK.md`
-
-Use the template at `references/runbook-template.md`. The emitted
-runbook has these sections:
-
-1. **Pre-deploy checklist** — what to set in Vercel's project
-   dashboard before clicking Deploy.
-2. **Leads — where messages go** — the two lead destinations, in
-   plain words:
-   - **Email (default)** — no database; each message is emailed to
-     the owner (`RESEND_API_KEY`, `AILK_LEAD_NOTIFICATION_TO`,
-     `AILK_LEAD_NOTIFICATION_FROM` on the API project).
-   - **Lead inbox (setup-database)** — `DATABASE_URL` set; messages
-     land in `/leads` and newsletter signups are collected.
-   With neither, production `/contact` shows the site's contact email
-   instead of the form. On a non-Vercel host, the API process needs
-   `NODE_ENV=production`.
-3. **Custom domain + DNS** — pointer at Vercel's domain docs.
-4. **Production callbacks for OAuth** — for consumers who used
-   `add-auth` and need to register prod redirect URIs.
-
-After write, grep the RUNBOOK for the two lead-destination headings
-(`Email (default)`, `Lead inbox (setup-database)`). Both must be
-present. If either is missing, the skill has a bug — flag with the
-literal error.
-
-### Step 7 — Closing summary
-
-Print:
-
-- Which artifacts were emitted vs skipped (per consumer's Step 3
-  choices).
-- Where leads will go (email, the lead inbox, or — with the Step 5a
-  warning repeated — nowhere), with a pointer to `RUNBOOK.md`'s
-  "Leads — where messages go" section.
-- A reminder that Vercel project-level env-vars need to be set in
-  the Vercel dashboard before deploy — `.env.example` is the
-  contract, not the values.
-- The next step: `vercel deploy` (or `git push` if the consumer is
-  using Vercel's GitHub integration).
-
-## Re-invocation
-
-The skill is idempotent. Re-running on a project with all three
-artifacts present asks the consumer how to handle each conflict
-(per Step 3). A consumer who picks **skip** for all three gets a
-no-op run with a "all artifacts already present, nothing to do"
-message.
-
-## Validation
-
-Before reporting "done":
-
-- `vercel.json` parses as JSON ✓
-- `.env.example` declares >= the count of vars in the template ✓
-- `RUNBOOK.md` contains both lead-destination headings
-  (`Email (default)`, `Lead inbox (setup-database)`) ✓
-- Step 5a ran: the consumer chose a lead destination, or saw the
-  no-destination warning ✓
-
-If any check fails, surface the failure to the consumer (not silent).
-
-## What this skill does NOT validate
-
-- That the consumer's Vercel project actually deploys. That's
-  `vercel deploy`'s job.
-- That env-var values in the consumer's Vercel dashboard are
-  correct or live. The skill never reads dashboard state.
-- That OAuth callback URLs in `add-auth`'s RUNBOOK are
-  registered in production OAuth apps. That's the consumer's job
-  pre-launch.
-
-## References
-
-- `references/vercel-json-template.md` — minimal viable `vercel.json`.
-- `references/env-vars-template.md` — `.env.example` structure with
-  placeholder values per category.
-- `references/runbook-template.md` — `RUNBOOK.md` with the two lead
-  destinations (Email (default), Lead inbox (setup-database)).
-
-## Coordination
-
-- **`setup-database`** — takes a site from no database to a working
-  lead inbox. Step 5a hands off to it; this skill never collects a
-  connection string.
-- **`add-auth`** — produces its own `RUNBOOK.md`
-  sections for OAuth setup (dev callback URLs). This skill's
-  RUNBOOK adds production callback URLs and merges with any
-  existing runbook content (not blindly overwrites).
-- **`@working-theory/env`** — at v1 a placeholder package, not yet a Zod
-  schema. This skill derives `.env.example` from the template, not
-  from a runtime schema. When `@working-theory/env` ships its schema, this
-  skill should be revised to read from it.
-- **Stripe sandbox-only** — hard-floor enforced globally. Emitted
-  `.env.example` uses `sk_test_*` placeholders, never `sk_live_*`.
-- **Cloudflare deferred** — neither CF Pages (deploy target) nor
-  CF KV / D1 / R2 (data layer) is in v1. Will ship as a coherent
-  follow-up PR.

package/templates/.claude/skills/setup-deploy/references/env-vars-template.md

@@ -1,192 +0,0 @@
-# `.env.example` Template
-
-The structure the `setup-deploy` skill emits at the consumer's
-project root. Placeholder values only — the skill never echoes a
-real secret.
-
-When `@working-theory/env` ships a Zod schema (currently a placeholder
-package), this template should be revised to derive from that
-schema instead. Until then, this file is the source of truth for
-what env vars an AILK consumer site reads.
-
-## Template
-
-```bash
-# AI Launch Kit — environment template
-# Copy this file to `.env.local` (gitignored) and fill in values.
-# Production values live in your deploy platform's dashboard
-# (Vercel project settings → Environment Variables).
-
-# ── Marketing / canonical domain ─────────────────────────────────
-# Your site's canonical public domain (no protocol).
-AILK_PUBLIC_DOMAIN=your-domain.com
-
-# ── Content backend ──────────────────────────────────────────────
-# AILK's MDX adapter is the default. Other adapters ship as
-# additive PRs later.
-CONTENT_BACKEND=mdx
-# Override the content directory. Default is <repo-root>/content.
-# AILK_CONTENT_ROOT=
-
-# ── Lead delivery ────────────────────────────────────────────────
-# Where contact-form messages go (RUNBOOK.md § "Leads — where
-# messages go"). Set these on the API project.
-#
-# Lead inbox — set by the `setup-database` skill. With it, messages
-# land in /leads and newsletter signups are collected.
-# DATABASE_URL=postgres://user:pass@host:5432/db
-# DATABASE_URL_NON_POOLED=postgres://user:pass@host:5432/db
-#
-# Email (default) — with no database, each message is emailed to you.
-# All three are required; a key alone sends nothing.
-# RESEND_API_KEY=
-# AILK_LEAD_NOTIFICATION_TO=you@your-domain.com
-# AILK_LEAD_NOTIFICATION_FROM=leads@your-domain.com
-#
-# With neither, /contact shows your contact email (content/_site.mdx
-# `contactEmail`) instead of the form in production.
-
-# ── API origin checks + checkout gate (apps/api) ─────────────────
-# Set both on the API project. Unset in production, the API logs a
-# startup warning for each and keeps running, but:
-# - without FRONTEND_URL, CORS and cookie origin checks are pinned to
-#   http://localhost:3000 and checkout answers 500 to a caller admitted
-#   without X-Internal-Auth;
-# - without OSS_API_INTERNAL_SECRET, the checkout route admits callers
-#   without the X-Internal-Auth header.
-# FRONTEND_URL is the site the browser loads (no trailing slash).
-# FRONTEND_URL=https://your-domain.com
-# Shared secret: the same value on the API and web projects.
-# Generate with: openssl rand -hex 32
-# OSS_API_INTERNAL_SECRET=
-
-# ── Auth — required env vars ─────────────────────────────────────
-# Set to "1" to require sign-in for protected routes; default is
-# auth-disabled / public.
-# AILK_AUTH_REQUIRED=1
-#
-# Better Auth secret — signs session cookies. REQUIRED in production:
-# apps/web/auth.ts throws in production without it. Generate with:
-#   openssl rand -base64 32
-# Local dev (next dev) uses a development fallback.
-# BETTER_AUTH_SECRET=
-#
-# The site's public origin — Better Auth builds OAuth callback URLs on
-# it and trusts only it. Set it in production; local dev can leave it
-# unset.
-# BETTER_AUTH_URL=https://your-domain.com
-
-# ── Auth — email sign-in (Resend) ────────────────────────────────
-# Activated when both AUTH_EMAIL_SERVER and AUTH_EMAIL_FROM are set.
-# Get a Resend API key at https://resend.com/api-keys.
-# AUTH_EMAIL_SERVER=smtp://resend:re_yourkeyhere@smtp.resend.com:465
-# AUTH_EMAIL_FROM=onboarding@resend.dev
-
-# ── Auth — Google OAuth ──────────────────────────────────────────
-# Activated when both GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET set.
-# Set up at https://console.cloud.google.com/apis/credentials.
-# Production callback: https://your-domain.com/api/auth/callback/google
-# GOOGLE_CLIENT_ID=
-# GOOGLE_CLIENT_SECRET=
-
-# ── Auth — GitHub OAuth ──────────────────────────────────────────
-# Activated when both GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET set.
-# Set up at https://github.com/settings/developers.
-# Production callback: https://your-domain.com/api/auth/callback/github
-# GITHUB_CLIENT_ID=
-# GITHUB_CLIENT_SECRET=
-
-# ── Stripe (sandbox keys only — sk_test_* / pk_test_*) ───────────
-# AILK is sandbox-only at v1. Live keys (sk_live_*, pk_live_*) are
-# hook-blocked from appearing in source.
-# Get test keys at https://dashboard.stripe.com/test/apikeys.
-# STRIPE_SECRET_KEY=sk_test_...
-# NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_...
-# Webhook signing secret — see Stripe Dashboard → Developers →
-# Webhooks → <endpoint> → Signing secret. Format: whsec_*.
-# STRIPE_WEBHOOK_SECRET=
-
-# ── Analytics — all off by default ───────────────────────────────
-# Each provider is independent. Set the env var(s) to enable.
-#
-# Vercel Analytics — built-in dashboard for Vercel deploys.
-# Requires Vercel hosting. Set to "true" to enable. Requires redeploy
-# after change (NEXT_PUBLIC_* values bake at build time).
-# NEXT_PUBLIC_VERCEL_ANALYTICS_ENABLED=
-#
-# Google Analytics 4 — gtag.js measurement. Requires consent in EU/UK/CA.
-# Get the measurement ID from analytics.google.com → Admin → Data Streams.
-# Format: G-XXXXXXXXXX. Requires redeploy after change.
-# NEXT_PUBLIC_GA_MEASUREMENT_ID=
-#
-# GA4 Measurement Protocol — server-side analytics secret.
-# Required alongside NEXT_PUBLIC_GA_MEASUREMENT_ID for server-side
-# lead/purchase events.
-# GA_API_SECRET=
-#
-# Google Search Console — verification meta tag. No script, no consent.
-# Get the token from search.google.com/search-console → Settings →
-# Ownership verification → HTML tag. Paste only the content="..." value.
-# GOOGLE_SITE_VERIFICATION=
-```
-
-## Categories the skill emits
-
-The template above groups vars into seven categories. Every emitted
-`.env.example` should hit each category at least with its header
-comment, even if the consumer hasn't activated any vars in that
-category — the comment block tells future-them what's available.
-
-Categories:
-
-1. Marketing / canonical domain
-2. Content backend
-3. Lead delivery (database or email)
-4. API origin checks + checkout gate
-5. Auth — required + per-provider
-6. Stripe (sandbox-only)
-7. Analytics
-
-## What the skill never includes
-
-- Real secret values. All values are placeholders or commented
-  examples.
-- Live Stripe keys. Sandbox-only at AILK v1.
-- Live Vercel deploy tokens. The Vercel CLI handles deploy auth via
-  `vercel login`.
-- Database connection strings with embedded passwords. Comments
-  show shape only.
-
-## Counting vars for validation
-
-The skill's Step 5 validation counts the declared (uncommented) vars
-the template emits and confirms the count is non-zero. Empty
-`.env.example` is a bug. Currently declared vars in the template:
-
-- `AILK_PUBLIC_DOMAIN`
-- `CONTENT_BACKEND`
-
-(All other entries are commented optional vars.) The skill should
-not require the consumer to set every commented var — they're
-opt-in. The two declared entries are the minimum the AILK scaffold
-needs to boot, even on a static-content-only site.
-
-## Merge logic
-
-If the consumer already has `.env.example`, the skill (per SKILL.md
-Step 3) offers merge / overwrite / skip. Merge logic:
-
-1. Read the existing file.
-2. For each line in this template that's not a comment-only line,
-   check whether the var name already appears anywhere in the
-   existing file (commented or uncommented).
-3. Vars **already present** are not modified — the consumer's
-   existing comments and value choices win.
-4. Vars **missing** are appended at the end of the existing file
-   under a new section:
-   ```
-   # ── Added by setup-deploy ────────────────────────────────
-   ```
-
-This avoids duplicating vars while still surfacing additions the
-template gained since the consumer's last run.

package/templates/.claude/skills/setup-deploy/references/runbook-template.md

@@ -1,204 +0,0 @@
-# `RUNBOOK.md` Template
-
-The `setup-deploy` skill emits this runbook at the consumer's
-project root. It documents pre-deploy steps and where the site's
-leads go — the two lead destinations, **Email (default)** and
-**Lead inbox (setup-database)**.
-
-The skill must verify both lead-destination headings are present
-after emit (per SKILL.md Step 6 validation). If either is missing,
-the skill has a bug.
-
-## Template
-
-```markdown
-# RUNBOOK — Production Operations
-
-This runbook is generated by the `setup-deploy` skill. It covers
-what to do before and after deploying to Vercel, plus the
-operational caveats AILK ships with.
-
-If you re-run `setup-deploy`, new sections may be appended at
-the end under "## Added by setup-deploy." 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 where leads go** — see "Leads — where messages go"
-      below. With neither an email key nor a database, your contact
-      page shows your contact email instead of the form in
-      production, and no messages are collected.
-- [ ] **On a host other than Vercel**, set `NODE_ENV=production` on
-      the API process — that is how it knows it is in production.
-- [ ] **Register production OAuth callbacks** if you used
-      `add-auth` and activated Google or GitHub. Each provider
-      needs the prod callback URL added to its OAuth app settings.
-
----
-
-## Leads — where messages go
-
-Where a contact-form message goes depends only on what you set on
-the **API** project:
-
-| You set                                   | A message…                                   |
-| ----------------------------------------- | -------------------------------------------- |
-| `DATABASE_URL`                            | lands in your lead inbox at `/leads`         |
-| the three email variables, no database    | is emailed to you                            |
-| neither (production)                      | is not collected — `/contact` shows your contact email instead of the form |
-| neither (`pnpm dev`)                      | is written to a local file, for testing      |
-
-A newsletter signup needs the database: without one, `/newsletter`
-offers no signup form. A visitor is never told a message was sent
-when it reached nobody.
-
-### Email (default)
-
-**When to pick:** you want messages in your inbox with no database
-to run. This is the default for a new site.
-
-**Setup:**
-
-1. Create an API key at <https://resend.com/api-keys> and verify the
-   domain you will send from (Resend Dashboard → Domains).
-2. On the **API** project in Vercel (Settings → Environment
-   Variables), set:
-   - `RESEND_API_KEY` — the key.
-   - `AILK_LEAD_NOTIFICATION_TO` — the address messages go to (yours).
-   - `AILK_LEAD_NOTIFICATION_FROM` — a sender on your verified domain.
-3. Redeploy the API.
-
-All three are required: a key without both addresses sends nothing.
-If Resend refuses a message, the visitor is told it could not be
-sent, so they can try again or email you directly.
-
-### Lead inbox (setup-database)
-
-**When to pick:** you want every message kept, searchable, in a
-lead inbox you review signed in — and newsletter signups collected.
-
-**Setup:** run the `setup-database` skill ("set up the database"). It
-walks you through provisioning Postgres, setting `DATABASE_URL`,
-running migrations, pinning you as the owner
-(`AILK_OPERATOR_EMAIL`), and sending one test message that must
-appear in `/leads` before it reports done. If the email variables
-are also set, you still get an email for each new lead.
-
----
-
-## 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 `add-auth`)
-
-If you activated Google or GitHub OAuth via `add-auth`,
-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 contact page shows an email address instead of the form"**
-  → the API has no lead destination. Set the three email variables,
-  or run `setup-database` (see "Leads — where messages go").
-- **"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 two headings (verbatim
-match). Both must be present:
-
-- `### Email (default)`
-- `### Lead inbox (setup-database)`
-
-If either 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 the "Leads — where messages go" section and its two
-   lead-destination headings are already present.
-3. Headings already present → not modified.
-4. Headings missing → append at the end of the existing file under:
-   ```
-   ## Added by setup-deploy
-   ```
-
-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.