create-ailk 0.10.0 → 0.11.0

package/templates/apps/web/app/.well-known/mcp.json/route.ts

@@ -12,7 +12,9 @@
  * the deployments whose MCP server registers it. Without that, a KEYED site
  * would register `start_purchase` while hiding it from its own manifest —
  * the surface disagreement `apps/mcp/__tests__/catalog-drift.test.ts` exists
- * to make impossible.
+ * to make impossible. The same single read also yields the licence features
+ * the deployment holds (#7136), which gate the five `feature`-tagged tools
+ * here exactly as they gate registration on the MCP server.
  *
  * Mirrors /.well-known/ai-plugin.json conventions: Response.json with a
  * conservative cache-control header.
@@ -23,7 +25,10 @@
  */
 
 import packageJson from "../../../package.json";
-import { resolveCommerceClaim } from "../../../src/lib/commerce-claim";
+import {
+  COMMERCE_FEATURE,
+  resolveLicenceFeatures,
+} from "../../../src/lib/commerce-claim";
 import { resolveBaseUrl } from "../../../src/lib/routes";
 
 import { buildMcpManifest } from "./build-manifest";
@@ -46,11 +51,13 @@ export async function GET(): Promise<Response> {
   // (apps/mcp running in HTTP mode). When set, the manifest includes it
   // as an additional transport descriptor for discovering agents.
   const mcpHttpUrlEnv = process.env["MCP_PUBLIC_HTTP_URL"];
+  const heldFeatures = await resolveLicenceFeatures();
 
   const manifest = buildMcpManifest({
     baseUrl: resolveBaseUrl(),
     ailkVersion: packageJson.version,
-    commerceClaimed: await resolveCommerceClaim(),
+    commerceClaimed: heldFeatures.includes(COMMERCE_FEATURE),
+    heldFeatures,
     // Spread conditional to satisfy exactOptionalPropertyTypes: omit the key
     // entirely when the env var is not set rather than passing undefined.
     ...(mcpHttpUrlEnv ? { mcpHttpUrl: mcpHttpUrlEnv } : {}),

package/templates/apps/web/src/lib/commerce-claim.ts

@@ -15,19 +15,28 @@
  * unlike `apps/mcp/src/lib/commerce-claim.ts`'s boot-time memoisation — so a
  * site that buys commerce after its last deploy starts serving immediately
  * rather than waiting on a redeploy.
+ *
+ * {@link resolveLicenceFeatures} (#7136) is the same single read, returning
+ * every licence feature the deployment holds: `/.well-known/mcp.json` gates
+ * the five `feature`-tagged MCP tools on it, from one call per request.
  */
 import { checkLicense } from "@working-theory/license";
 
 /** The licence `features[]` claim that turns the commerce add-on on. */
-const COMMERCE_FEATURE = "commerce";
+export const COMMERCE_FEATURE = "commerce";
 
-export async function resolveCommerceClaim(): Promise<boolean> {
+/** The licence features this deployment positively holds — `[]` when the
+ * licence is revoked, carries no `features` array, or cannot be read. */
+export async function resolveLicenceFeatures(): Promise<readonly string[]> {
   try {
     const result = await checkLicense();
-    return (
-      result.revoked !== true && result.features.includes(COMMERCE_FEATURE)
-    );
+    if (result.revoked === true) return [];
+    return Array.isArray(result.features) ? result.features : [];
   } catch {
-    return false;
+    return [];
   }
 }
+
+export async function resolveCommerceClaim(): Promise<boolean> {
+  return (await resolveLicenceFeatures()).includes(COMMERCE_FEATURE);
+}

package/templates/content/_site.mdx

@@ -49,11 +49,13 @@ theme:
 This file is your site's canonical configuration. Edit the frontmatter above to
 set your site name, base URL, default locale, and identity.
 
-`siteIdentity.kind` takes one of three values:
+`siteIdentity.kind` takes one of four values:
 
-  - Organization  — a company, agency, nonprofit, or team
-  - Person        — a solo practitioner, consultant, or personal site
-  - LocalBusiness — a business with a physical location customers visit
+  - Organization        — a company, agency, nonprofit, or team
+  - Person              — a solo practitioner, consultant, or personal site
+  - LocalBusiness       — a business with a physical location customers visit
+  - SoftwareApplication — a product's own site, when its maker has a site of
+                          its own (see below)
 
 `siteIdentity.secondary` (optional) names a second entity the site is about, and
 every page's structured data carries it:
@@ -73,6 +75,23 @@ For example, nested under `siteIdentity:`
       name: Acme App
       url: https://example.com/app
 
+`kind: SoftwareApplication` is the inverse of that product secondary: the
+product is the site's entity, and its maker — whose own site already declares
+it — is named as `publisher` by the stable `@id` that site publishes. It takes
+the product's `name` and `url` (optional `logo`, `description`,
+`applicationCategory`, `operatingSystem`, `sameAs`) and a required `publisher`
+with an `id` URL and an optional `name`; it takes no `secondary`. No second
+Organization is declared here — every page's structured data points at the
+maker's `@id`, and the home page's main entity is the product. For example:
+
+    siteIdentity:
+      kind: SoftwareApplication
+      name: Acme App
+      url: https://acme-app.example
+      publisher:
+        id: https://acme.example/#organization
+        name: Acme Inc.
+
 `sameAs` is the list of URLs that are unambiguously the same entity as you —
 your LinkedIn company page, your GitHub org, your X profile. Answer engines use
 it to reconcile your site with the rest of your presence, so it is worth

package/templates/database/CHANGELOG.md

@@ -1,5 +1,12 @@
 # @working-theory/database
 
+## 0.30.0
+
+### Patch Changes
+
+- Updated dependencies []:
+  - @working-theory/validation@0.30.0
+
 ## 0.29.0
 
 ### Patch Changes

package/templates/database/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@working-theory/database",
-  "version": "0.29.0",
+  "version": "0.30.0",
   "license": "Apache-2.0",
   "publishConfig": {
     "access": "public"

package/versions.json

@@ -1,39 +1,40 @@
 {
-  "@working-theory/admin-ui": "0.29.0",
-  "@working-theory/aeo": "0.29.0",
-  "@working-theory/agent-context": "0.29.0",
+  "@working-theory/admin-ui": "0.30.0",
+  "@working-theory/aeo": "0.30.0",
+  "@working-theory/agent-context": "0.30.0",
   "@working-theory/agent-contract": "0.1.0",
   "@working-theory/agent-memory": "0.0.0",
   "@working-theory/ai": "0.1.0",
-  "@working-theory/analytics": "0.29.0",
-  "@working-theory/api-client": "0.29.0",
+  "@working-theory/analytics": "0.30.0",
+  "@working-theory/api-client": "0.30.0",
   "@working-theory/cda-filesystem": "0.0.0",
-  "@working-theory/cli": "0.29.0",
-  "@working-theory/common": "0.29.0",
+  "@working-theory/cli": "0.30.0",
+  "@working-theory/common": "0.30.0",
   "@working-theory/consent": "0.1.0",
-  "@working-theory/content-adapters": "0.29.0",
-  "@working-theory/content-projection": "0.29.0",
-  "@working-theory/email": "0.29.0",
+  "@working-theory/content-adapters": "0.30.0",
+  "@working-theory/content-projection": "0.30.0",
+  "@working-theory/email": "0.30.0",
   "@working-theory/env": "0.0.0",
-  "@working-theory/eslint-config": "0.29.0",
-  "@working-theory/fumadocs-schema": "0.29.0",
+  "@working-theory/eslint-config": "0.30.0",
+  "@working-theory/fumadocs-schema": "0.30.0",
   "@working-theory/ids": "0.8.0",
-  "@working-theory/jsonld": "0.29.0",
-  "@working-theory/license": "0.29.0",
-  "@working-theory/metadata": "0.29.0",
-  "@working-theory/observability": "0.29.0",
-  "@working-theory/page-renderer": "0.29.0",
-  "@working-theory/schema": "0.29.0",
-  "@working-theory/schema-pack-registry": "0.29.0",
-  "@working-theory/schema-validator": "0.29.0",
-  "@working-theory/sections-registry": "0.29.0",
-  "@working-theory/site-config": "0.29.0",
-  "@working-theory/stripe-client": "0.29.0",
-  "@working-theory/templates": "0.29.0",
-  "@working-theory/theme": "0.29.0",
-  "@working-theory/ui": "0.29.0",
-  "@working-theory/validation": "0.29.0",
-  "@working-theory/web-i18n": "0.29.0",
+  "@working-theory/jsonld": "0.30.0",
+  "@working-theory/license": "0.30.0",
+  "@working-theory/metadata": "0.30.0",
+  "@working-theory/observability": "0.30.0",
+  "@working-theory/page-renderer": "0.30.0",
+  "@working-theory/plugin-mcp": "0.1.1",
+  "@working-theory/schema": "0.30.0",
+  "@working-theory/schema-pack-registry": "0.30.0",
+  "@working-theory/schema-validator": "0.30.0",
+  "@working-theory/sections-registry": "0.30.0",
+  "@working-theory/site-config": "0.30.0",
+  "@working-theory/stripe-client": "0.30.0",
+  "@working-theory/templates": "0.30.0",
+  "@working-theory/theme": "0.30.0",
+  "@working-theory/ui": "0.30.0",
+  "@working-theory/validation": "0.30.0",
+  "@working-theory/web-i18n": "0.30.0",
   "@working-theory/billing-client": "0.0.0",
   "@working-theory/branding": "0.0.0",
   "@working-theory/license-client": "0.0.0",
@@ -41,12 +42,12 @@
   "@working-theory/marketing-api-client": "0.0.0",
   "@working-theory/partner-session": "0.0.0",
   "@working-theory/preview-protocol": "0.0.0",
-  "@working-theory/ui-commerce": "0.23.6",
-  "@working-theory/ui-docs-blog": "0.23.6",
-  "@working-theory/ui-scheduling": "0.23.6",
-  "@working-theory/ui-signal-collectors": "0.24.4",
+  "@working-theory/ui-commerce": "0.23.7",
+  "@working-theory/ui-docs-blog": "0.23.7",
+  "@working-theory/ui-scheduling": "0.23.7",
+  "@working-theory/ui-signal-collectors": "0.24.5",
   "@working-theory/web": "0.0.0",
   "@working-theory/api": "1.0.0",
   "@working-theory/mcp": "0.0.0",
-  "@working-theory/database": "0.29.0"
+  "@working-theory/database": "0.30.0"
 }

package/templates/.claude/skills/README.md

@@ -1,37 +0,0 @@
-# Skills
-
-Skills are reusable Claude Code workflows scoped to this project. Each
-lives in its own subdirectory with a `SKILL.md` describing when to use
-it and how it works.
-
-The eight skills below ship with this project. Claude Code discovers
-them automatically at session start — nothing to install or enable.
-
-## Available skills
-
-| Skill          | Purpose                                                                                                      |
-| -------------- | -------------------------------------------------------------------------------------------------------------- |
-| `add-page`     | Add a page this site can serve — its content file, structured data and nav link — adding a missing route with `create-ailk add-route` first. Also documents the `schema:` frontmatter override for any page. |
-| `update-page`  | Rename a page — give it a new URL and/or a new title — in one plan-then-confirm pass: its content files, its own route folder, exact internal links and the manifest row move together, and the old URL gets a permanent redirect. |
-| `add-auth`     | Activate auth providers — magic-link via Resend, Google OAuth, GitHub OAuth.                                  |
-| `setup-deploy` | Emit deploy configuration — `vercel.json`, `.env.example`, and `RUNBOOK.md` — for a Vercel deploy. Asks where leads go (email or a database) and warns when neither is set. |
-| `setup-database` | Take the site from no database to a working lead inbox: provision Postgres, create the tables, pin the owner, and verify one test message lands in `/leads`. |
-| `check-site`   | Run `ailk-audit --json` and explain the score and findings in plain language.                                 |
-| `fill-page`    | Fill one page's section content from a category profile: labelled sample content (tier 1) or your own first draft from a short intake (tier 2). |
-| `upgrade-plan` | Compare Free, Pro, Pro Plus, Agency and the commerce add-on side by side, with the prices the public pricing page publishes right now, and recommend one option for this site with a reason. |
-
-`scaffold-commerce` is delivered with the commerce module (`--modules commerce`, licensed).
-
-## How a skill works
-
-Each subdirectory holds:
-
-- `SKILL.md` — when to invoke, what it produces, what it requires.
-- Any supporting prompt fragments, code templates, or reference
-  files the skill loads at runtime.
-
-## Adding your own
-
-To add a project-specific skill, create a folder here with a
-`SKILL.md` describing it. Claude Code will discover it automatically
-on session start. See the skills above for examples of the format.

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

@@ -1,313 +0,0 @@
----
-name: add-auth
-description: Activate the site's sign-in providers (email-and-password, 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 email / Google / GitHub sign-in 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 `apps/web/auth.ts` and does NOT emit any pages.
----
-
-# add-auth
-
-Activate one or more sign-in providers on an AILK site by writing the
-env vars `getActiveProviderIds()` (`apps/web/lib/auth-env.ts`) reads
-to detect them, plus a `RUNBOOK.md` that documents the OAuth-app-creation
-steps for the consumer's records.
-
-The site's auth library is **Better Auth**, configured in
-`apps/web/auth.ts` and mounted at `apps/web/app/api/auth/[...all]/route.ts`.
-
-## When to use
-
-The user has a working AILK site (post-`pnpm create ailk`) and wants
-to gate routes behind sign-in or accept email, Google or GitHub
-sign-in. Phrases that should trigger this skill:
-
-- "wire up auth" / "add login" / "set up sign-in"
-- "I want users to log in"
-- "enable Google sign-in" / "enable GitHub login"
-- "set up email login" / "set up magic-link auth"
-- "add OAuth"
-
-A magic link is not wired: Better Auth core ships no magic-link
-provider, so the `email` provider id switches on email-and-password
-sign-in instead. Say so when the consumer asks for a magic link, and
-offer `email` on those terms.
-
-Skip this skill when:
-
-- The user wants a new page. The site already ships its sign-in and
-  sign-up pages (`apps/web/app/[locale]/(auth)/`), which list whichever
-  providers are active. Any other page is `add-page`'s job.
-- The user is asking about a third-party provider outside the three
-  provider ids below (Apple, Microsoft, Twitter, etc.). Adding one is a
-  code change to `apps/web/auth.ts`, not env wiring. 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 `setup-deploy`
-  or a future deploy skill. Note this and stop.
-
-## The provider ids
-
-`getActiveProviderIds()` in `apps/web/lib/auth-env.ts` returns a
-provider id only when every one of its env vars is set to a non-empty
-value:
-
-| Provider id | Env vars                                    | What it switches on                                             |
-| ----------- | ------------------------------------------- | --------------------------------------------------------------- |
-| `email`     | `AUTH_EMAIL_SERVER` + `AUTH_EMAIL_FROM`     | Email-and-password sign-in (Better Auth's `emailAndPassword`)   |
-| `google`    | `GOOGLE_CLIENT_ID` + `GOOGLE_CLIENT_SECRET` | Google OAuth (Better Auth's `socialProviders.google`)           |
-| `github`    | `GITHUB_CLIENT_ID` + `GITHUB_CLIENT_SECRET` | GitHub OAuth (Better Auth's `socialProviders.github`)           |
-
-`references/env-vars.md` is the full contract, including the auxiliary
-vars (`BETTER_AUTH_URL`, `BETTER_AUTH_SECRET`, `AILK_AUTH_REQUIRED`,
-`AILK_AUTH_SIGNUP_OPEN`, `AILK_AUTH_PASSWORD_RESET`,
-`AUTH_EMAIL_WEBHOOK_SECRET`).
-
-## What this skill does (and does not do)
-
-**Does:**
-
-- Reads `.env.local` to see which provider ids are already active.
-- Asks the consumer which of the three provider ids (`email`,
-  `google`, `github`) they want to activate _this session_.
-- For each picked provider, walks the consumer through
-  OAuth-app creation (`google` / `github`) or the Resend sender setup
-  (`email`), then writes the resulting values to `.env.local`.
-- Checks that sign-in has a database to write to. Better Auth always
-  runs its Prisma adapter with database sessions, so sign-in needs
-  `DATABASE_URL` and the auth tables in place.
-- Writes (or merges) a `RUNBOOK.md` in the consumer's repo root
-  with the same setup instructions the consumer just followed, so
-  they can refer back later or hand to a collaborator.
-
-**Does not:**
-
-- Modify `apps/web/auth.ts`. The three provider ids are env-var-driven
-  — `apps/web/auth.ts` reads `getActiveProviderIds()` at startup and
-  builds only the providers it returns. No code changes are needed.
-- Create any new files under `app/`, `pages/`, or `content/`. The
-  emit is limited to `.env.local` writes and a `RUNBOOK.md` write.
-- Set up production callback URLs. Dev-mode (`http://localhost:3000`)
-  only at v1.
-- Add, remove, or modify any provider in `apps/web/auth.ts`. A
-  provider the consumer added there by hand (e.g., Apple) is preserved
-  as-is and never touched by this skill.
-- Accept production OAuth credentials. If the consumer pastes a
-  production-looking secret, that's acceptable, but the runbook still
-  documents only the dev callback URL.
-
-## The mechanic
-
-### Step 1 — Show the menu
-
-Greet the consumer and present the three provider ids, marking
-which are already active (env vars present in `.env.local`):
-
-```
-Which sign-in providers do you want to activate?
-
-  [ ] email   (email-and-password sign-in)
-  [ ] google  (Google OAuth)
-  [ ] github  (GitHub OAuth)
-
-You can pick any subset, including "none of the above" (in which case
-this skill exits without writing anything). You can also re-run this
-skill later to activate more providers — already-active providers
-will be skipped automatically.
-```
-
-If `.env.local` already has any of these active, mark them:
-
-```
-  [x] email   (already active — AUTH_EMAIL_SERVER + AUTH_EMAIL_FROM are set)
-  [ ] google  (Google OAuth)
-  [ ] github  (GitHub OAuth)
-```
-
-Wait for the consumer to pick a subset. Then, for each picked
-provider, run the matching sub-flow.
-
-### Step 2 — Run per-provider sub-flows
-
-#### `email` sub-flow
-
-1. Tell the consumer: _"The `email` provider turns on
-   email-and-password sign-in. It switches on when `AUTH_EMAIL_SERVER`
-   and `AUTH_EMAIL_FROM` are both set. You'll need a Resend API key
-   (free tier is fine for development). Get one at
-   <https://resend.com/api-keys>."_
-2. Wait for the consumer to paste the API key.
-3. Ask for the `AUTH_EMAIL_FROM` address. This must be a verified
-   sender on the consumer's Resend account. For development it's
-   common to use `onboarding@resend.dev` (Resend's shared dev
-   sender). Mention that.
-4. Construct `AUTH_EMAIL_SERVER` as
-   `smtp://resend:<API_KEY>@smtp.resend.com:465`.
-5. Write to `.env.local`:
-   ```
-   AUTH_EMAIL_SERVER=smtp://resend:re_...@smtp.resend.com:465
-   AUTH_EMAIL_FROM=onboarding@resend.dev
-   ```
-6. Tell the consumer who actually sends the mail. `apps/web` sends
-   none: `AUTH_EMAIL_SERVER` is read for its presence only, and
-   `apps/web/lib/auth-email.ts` relays each auth email (verification,
-   password reset) to `apps/api`, which sends it with `RESEND_API_KEY`
-   from `AUTH_EMAIL_FROM`. For that mail to go out, `RESEND_API_KEY`
-   and `AUTH_EMAIL_FROM` must be set for `apps/api`, and
-   `AUTH_EMAIL_WEBHOOK_SECRET` (any long random string, the same value)
-   for both apps. Password reset — and the verification mail with it —
-   is off until `AILK_AUTH_PASSWORD_RESET=1`, and also needs
-   `BETTER_AUTH_URL` and `BETTER_AUTH_SECRET` (`resetSendConfigured()`
-   in `apps/web/lib/auth-env.ts`).
-7. Tell the consumer that public sign-up stays closed until they set
-   `AILK_AUTH_SIGNUP_OPEN=1` (read by `isSignUpOpen()` in
-   `apps/web/lib/auth-env.ts`). With sign-up closed and `email` the only
-   provider, nobody can create the first account — so either open
-   sign-up long enough to create it, or activate `google` or `github`
-   as well. Ask which they want; leave the flag unset otherwise.
-
-#### `google` sub-flow
-
-1. Tell the consumer the steps in chat AND queue the same content for
-   the runbook (see Step 3). Steps:
-   - Go to <https://console.cloud.google.com/apis/credentials>.
-   - Click **Create Credentials → OAuth client ID**. If prompted,
-     configure the OAuth consent screen first (**External** → fill
-     name, support email, developer contact email; Better Auth
-     requests the scopes at runtime, so leave the scope list empty).
-   - Application type: **Web application**.
-   - Name: anything (e.g., "AILK dev").
-   - **Authorized redirect URIs** — add exactly:
-     `http://localhost:3000/api/auth/callback/google`
-   - Click **Create**. Copy the **Client ID** and **Client secret**
-     from the dialog.
-2. Wait for the consumer to paste both values.
-3. Write to `.env.local`:
-   ```
-   GOOGLE_CLIENT_ID=...
-   GOOGLE_CLIENT_SECRET=...
-   ```
-
-#### `github` sub-flow
-
-1. Tell the consumer the steps in chat AND queue the same content for
-   the runbook. Steps:
-   - Go to <https://github.com/settings/developers>.
-   - Click **New OAuth App**.
-   - Application name: anything (e.g., "AILK dev").
-   - Homepage URL: `http://localhost:3000`
-   - **Authorization callback URL** — add exactly:
-     `http://localhost:3000/api/auth/callback/github`
-   - Click **Register application**. Generate a new client secret.
-     Copy the **Client ID** and **Client secret**.
-2. Wait for the consumer to paste both values.
-3. Write to `.env.local`:
-   ```
-   GITHUB_CLIENT_ID=...
-   GITHUB_CLIENT_SECRET=...
-   ```
-
-### Step 3 — Write the RUNBOOK
-
-After all picked providers are activated, write
-`RUNBOOK.md` (or merge into existing) at the consumer's repo root.
-The runbook captures the OAuth-app-creation steps and Resend setup
-the consumer just walked through, so they can hand it to a teammate
-or refer back later.
-
-Use `references/oauth-app-setup.md` as the template. Replace
-`<provider>` headings as appropriate, and only include sections for
-providers actually activated this session. If `RUNBOOK.md` already
-exists with sections for already-active providers, do not
-duplicate — add only the new sections beneath any existing content.
-
-### Step 4 — Check the database
-
-Sign-in always reads and writes the database: `apps/web/auth.ts`
-runs Better Auth's Prisma adapter, and sessions are rows, not
-cookie-only tokens. There is no database-free mode. Before printing
-the closing summary, check:
-
-- `DATABASE_URL` (and `DATABASE_URL_NON_POOLED`, which the migrations
-  use) is set in `.env.local`. If it is not, sign-in will fail on its
-  first request — point the consumer at the `setup-database` skill,
-  which sets both and creates the tables.
-- The auth tables exist. The Prisma schema is `database/schema.prisma`
-  (Prisma reads the whole `database/` folder; the `User`, `Session`,
-  `Account` and `Verification` models are in `database/auth/schema.prisma`).
-  If the consumer has not applied the migrations yet, they run
-  `pnpm db:migrate:deploy`.
-
-State what you found in the closing summary so the consumer is never
-surprised:
-
-> "Sign-in stores its users and sessions in your database (the
-> `User` and `Session` tables). Run `pnpm db:migrate:deploy` if you
-> haven't applied the migrations yet."
-
-or, when `DATABASE_URL` is unset:
-
-> "Sign-in needs a database and none is configured yet. Run the
-> `setup-database` skill before you try to sign in."
-
-### Step 5 — Closing summary
-
-Print:
-
-- Which provider ids are now active (subset picked this session +
-  already-active providers).
-- What Step 4 found about the database.
-- 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 `setup-deploy` for production callback URLs and
-  `BETTER_AUTH_URL` / `BETTER_AUTH_SECRET` when the consumer is ready
-  to deploy — a production deploy fails without `BETTER_AUTH_SECRET`.
-
-## Re-invocation
-
-The skill is idempotent. On a second run, the menu in Step 1 marks
-already-active providers with `[x]` (read from `.env.local`), and
-the per-provider sub-flows skip those and only run for the new ones.
-The closing summary lists everything, not just what changed this
-session.
-
-If the consumer wants to _change_ a previously-activated provider's
-secrets (e.g., rotated their Google Client Secret), they should pick
-that provider in the menu and the sub-flow will overwrite the
-existing values in `.env.local`. Confirm before overwriting.
-
-## Customization preservation
-
-If `apps/web/auth.ts` has been modified by the consumer to add a
-third-party provider (e.g., Apple), this skill leaves that file
-completely untouched. The skill never edits `apps/web/auth.ts`.
-Activation of the three provider ids happens entirely through env
-vars — `getActiveProviderIds()` in `apps/web/lib/auth-env.ts` is what
-reads them at startup.
-
-## What "activation" means under the hood
-
-- **The provider list is computed at startup from env-var presence**
-  by `getActiveProviderIds()` in `apps/web/lib/auth-env.ts`.
-- `apps/web/auth.ts` consumes that list: `google` and `github` become
-  Better Auth `socialProviders` entries built from their env vars, and
-  `email` switches `emailAndPassword` on.
-- A provider id is returned only when every one of its env vars is set
-  (the table under § The provider ids).
-- A site with zero auth env vars boots cleanly with no active
-  providers (`getActiveProviderIds()` returns an empty array).
-
-This means the skill's job is purely env-var wiring + documentation.
-
-## References
-
-- `references/oauth-app-setup.md` — RUNBOOK template the skill instantiates per session.
-- `references/env-vars.md` — env-var contract (which vars activate which provider id).
-
-## Coordination
-
-- **`add-page`** — any new page. This skill emits no pages; the
-  sign-in and sign-up pages already ship.
-- **`setup-database`** — `DATABASE_URL` and the tables sign-in
-  needs.
-- **`setup-deploy`** — production callback URLs and the production
-  auth env vars. v1 of this skill is dev-only.