@aotter/mantle 0.0.11-alpha.25 → 0.0.11-alpha.27

package/README.md

@@ -31,7 +31,11 @@ import { mountServerEndpoints } from "@aotter/mantle/cloudflare";
 
 ## Getting started
 
-Recommended path: open the Mantle landing page, pick an archetype and theme, then paste the generated prompt into Claude Code / Cursor / Codex. The install Skill asks the right follow-up questions and then runs the scaffolder for you.
+Recommended path: open the Mantle landing page, answer the launch
+questions, sign in with GitHub, then paste the generated launch command
+into Claude Code / Cursor / Codex. The short-lived launch session carries
+the scaffold values, so the agent can run `create-mantle launch` first
+and continue with provisioning.
 
 Available starter keys and direct scaffolder usage live in [`aotter/mantle-starters`](https://github.com/aotter/mantle-starters): `presence`, `publication`, `intake`, `transaction`, and `blank`. See `skills/install` in the [Mantle repo](https://github.com/aotter/mantle/tree/develop/skills/install) for the full agent-driven install flow.
 

package/docs/adr/0014-auth-better-auth-and-multi-tenant-mcp.md

@@ -242,17 +242,20 @@ The pivot point — when to extract — is when the second adapter (`mantle-netl
 
 None. Pre-v0.1.0 has no external consumers. Existing demo deployments tear down + re-bootstrap from the migrated `0.0.x-alpha` release.
 
-### Skills + prompts
+### Skills + launch handoff
 
-`docs/prompts/publication.{en,zh-TW}.md` reference `<worker_url>/staff/mcp` for staff-targeted MCP handoff. `skills/install/SKILL.md` and `skills/provision/SKILL.md` document the dual handoff. Provision Skill's final report distinguishes:
+The Mantle landing launch session and generated repo-local
+`mantle:provision` skill document the dual MCP handoff. Provision's final
+report distinguishes:
 
 ```
 Public site:    https://<worker>.workers.dev/
-Staff MCP URL:  https://<worker>.workers.dev/staff/mcp     (give to your owner agent)
+Staff MCP URL:  https://<worker>.workers.dev/mcp/staff     (give to your owner agent)
 User MCP URL:   https://<worker>.workers.dev/mcp           (give to visitors / their agents)
 ```
 
-The publication starter repo's production smoke recipe uses `/staff/mcp` for the MCP operator smoke step.
+The publication starter repo's production smoke recipe uses `/mcp/staff`
+for the MCP operator smoke step.
 
 ### Future-proof for v0.2
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aotter/mantle",
-  "version": "0.0.11-alpha.25",
+  "version": "0.0.11-alpha.27",
   "description": "Umbrella entry for @aotter/mantle. Adopters install this one package and import from subpaths: /spec, /runtime, /cloudflare, /admin-ui. Sub-packages remain individually installable on npm for tooling / alt-adapter authors. The Netlify adapter ships as a private workspace stub in v0.1 — its subpath will be added when the impl lands in v0.2.",
   "license": "Apache-2.0",
   "homepage": "https://mantle.tools/",
@@ -47,10 +47,10 @@
     "README.md"
   ],
   "dependencies": {
-    "@aotter/mantle-admin-ui": "0.0.11-alpha.25",
-    "@aotter/mantle-runtime": "0.0.11-alpha.25",
-    "@aotter/mantle-spec": "0.0.11-alpha.25",
-    "@aotter/mantle-cloudflare": "0.0.11-alpha.25"
+    "@aotter/mantle-admin-ui": "0.0.11-alpha.27",
+    "@aotter/mantle-cloudflare": "0.0.11-alpha.27",
+    "@aotter/mantle-runtime": "0.0.11-alpha.27",
+    "@aotter/mantle-spec": "0.0.11-alpha.27"
   },
   "peerDependencies": {
     "@cloudflare/workers-oauth-provider": "^0.7.0",

package/skills/install/SKILL.md

@@ -1,13 +1,16 @@
 ---
 name: mantle install
-description: Install a mantle consumer project. Preferred path consumes a landing-created launch session and scaffolds immediately via create-mantle; fallback path is interview-driven, elicits the user's purpose/audience/timing/identity, then scaffolds deterministically and continues to provision. Use when the user pasted a launch command/session URL, a composed-skill URL generated by the landing page, or when starting from an empty repo.
+description: Install a mantle consumer project. Preferred path consumes a landing-created launch session and scaffolds immediately via create-mantle. Manual fallback collects the exact create-mantle flags, scaffolds deterministically, then continues to provision. Use when the user pasted a launch command/session URL or when starting from an empty repo.
 when_to_invoke: |
-  Empty repo + landing-page launch command/session URL; empty repo + landing-page composed-skill prompt; or the user describes a site they want to build. A composed URL may inline the per-archetype hint with this brief.
+  Empty repo + landing-page launch command/session URL, or empty repo + user wants to create a Mantle site without landing.
 ---
 
 # mantle install
 
-You're installing a mantle site for the user. If the user arrived from the landing launch flow, a short-lived launch session already carries the launch-critical values. If the user arrived from the older composed-prompt flow, the composed URL inlined this brief plus the per-archetype hint — archetype-specific register cues are in the same document.
+You're installing a mantle site for the user. If the user arrived from
+the landing launch flow, a short-lived launch session already carries
+the launch-critical values. Treat that session as the source of truth
+and scaffold first.
 
 ## Ground truth
 
@@ -94,7 +97,7 @@ After it returns:
 
 Do not ask content/voice questions before scaffold. The natural point for user conversation is after the site exists locally and, preferably, after provision has produced a working URL. If the user explicitly wants to revise content before provision, keep it to the same small adjustment window described later in this Skill.
 
-## Preflight — before the fallback interview
+## Preflight — before manual fallback
 
 Verify the environment can run the flow. Don't waste the user's time interviewing for a site we can't build:
 
@@ -111,13 +114,17 @@ If any is missing or below the minimum, surface install hints once and stop unti
 
 Also confirm the current working directory is an appropriate parent directory for the new project, and that no child directory already exists with the authorized `<<PROJECT_NAME>>`. `create-mantle` writes into `./<<PROJECT_NAME>>`; collisions with pre-existing files are surprising and rarely what the user wanted.
 
-Don't proceed to the fallback interview until preflight passes.
+Do not proceed to manual fallback until preflight passes.
 
-## The interview
+## Manual fallback
 
-Use this section only when there is no valid launch session. With a launch session, the landing flow already supplied the scaffold values and the agent should run launch first.
+Use this only when there is no valid launch session. The manual path is
+for development, recovery, or a user who did not start from landing. It
+is not the primary UX.
 
-There's no fixed question list. The archetype hint above (composed in by landing) carries **Interview probes to emphasize** — 4 archetype-tailored questions written for this specific archetype's concerns. That's your spine. Free-form follow-ups based on what surfaces. You decide order. You decide when you have enough.
+Ask only for the values that the `create-mantle` command truly needs.
+Keep it one question at a time and confirm the exact values before
+running the command.
 
 ### Goal — what you must land before dispatch
 
@@ -125,22 +132,25 @@ Listed in discovery order — purpose comes first, brand near the end. **Do not
 
 | Value | For |
 |---|---|
-| **purpose / audience / emotional weight** | site summary + future content direction; surfaces through the archetype probes |
+| **purpose / audience** | one-line description and locale choice |
 | **audience scope + locales** | `--locales` (count + first is canonical) |
 | **description** | `--description` — one-line site identity, agent-drafted in user's language |
 | **summary** | `--summary` — one-line install-moment marker, agent-drafted in user's language |
 | **brand** | `--brand` — proposed by you after purpose + audience texture is in; user picks or supplies their own |
-| **github identity** | `--github-owner` — pure config; ask near the end |
+| **github identity** | `--github-owner` and optional `--admin-github-login` |
 
-archetype is already known (the composed URL pinned it). Every value above must be set with the user's **explicit confirmation** before you dispatch — never guess from email / folder name / archetype name.
+Every value above must be set with the user's explicit confirmation
+before you dispatch. Do not guess from email, folder name, or the
+language of the conversation.
 
 ### Multi-round purpose discovery — start here, not with brand
 
-Open with **what's this site for** — not the brand name. Don't ask cold ("describe your site in your own words"); that puts the user on the spot. Use the archetype hint's **Interview probes** (composed in below) as your discovery spine. Ask the first probe naturally, in the user's language, as an open question — don't fabricate multiple-choice options if the probe is written as open-ended. The picker step already happened at the landing page (`?type=` and `?theme=` in the URL); the probes here are about texture, not branching.
+Open with **what's this site for** — not the brand name. Don't ask cold
+for a full brief. Ask one simple question, summarize back, then move to
+the next required value.
 
-User answers → react → ask the next probe. **One probe per turn, not all four at once.** This is the multi-round shape. After 2–4 turns you have enough texture to propose brand candidates (Brand stance below) and synthesize description + summary drafts.
-
-If a probe is phrased with options in the archetype hint, you may offer them as a picker — but most presence / publication / intake probes are intentionally open. Translate every probe (and your framing) into the user's language before presenting.
+User answers -> react -> ask the next missing value. One question per
+turn. Stop as soon as the command values are known.
 
 ### Stances (the few non-archetype rules)
 
@@ -196,34 +206,55 @@ Invoking the `create-mantle` release tarball is **not low-risk work**. The comma
 
 Wrong values ship into the user's first-load impression and cannot be cleanly walked back without wiping the scaffold and re-scaffolding from empty.
 
-**Auto Mode's contract has four clauses. Clauses 1–3 say "execute immediately / minimize interruptions / prefer action". Clause 4 is the carve-out: do not take overly destructive actions without authorization.** This Skill classifies the scaffolder invocation under clause 4. Each marker (`<<...>>`) in the composed `## Run this` block (see end of this document) must be a value the user has personally seen and nodded on. Auto-derivation — from the user's email, the current working directory's name, the archetype query, the theme query, or "the locale of the message the user wrote to me" — is **not** authorization. That kind of inference is what Auto Mode's clauses 1–3 want for low-risk work. This Skill specifically does not accept it for these marker values.
+**Auto Mode's contract has four clauses. Clauses 1–3 say "execute immediately / minimize interruptions / prefer action". Clause 4 is the carve-out: do not take overly destructive actions without authorization.** This Skill classifies the scaffolder invocation under clause 4. Each create-time value must be either carried by a valid landing session or explicitly confirmed by the user. Auto-derivation — from the user's email, the current working directory's name, the archetype query, the theme query, or "the locale of the message the user wrote to me" — is **not** authorization. That kind of inference is what Auto Mode's clauses 1–3 want for low-risk work. This Skill specifically does not accept it for scaffolding values.
 
 If you have not had a turn where the user looked at the exact value and replied affirmatively (or supplied a replacement), the value is unauthorized.
 
-Launch-session exception: when the user hands you a landing-created `create-mantle launch --session ...` command, the landing session is the explicit authorization for those scaffold values. Your job is to validate/run it, not to repeat the full interview before scaffold. If the session is invalid or expired, stop and ask the user to regenerate it from the landing page; do not infer replacement values.
+Launch-session exception: when the user hands you a landing-created
+`create-mantle launch --session ...` command, the landing session is the
+explicit authorization for those scaffold values. Your job is to
+validate/run it, not to repeat manual fallback before scaffold. If the
+session is invalid or expired, stop and ask the user to regenerate it
+from the landing page; do not infer replacement values.
 
 ### Prerequisites — each parameter must be user-authorized before invocation
 
 Same discovery order as the Goal table above — purpose first, brand later. The order matters because it reflects the interview shape, not arbitrary alphabetization.
 
-| Value | Marker | Authorized when |
-|---|---|---|
-| **purpose / audience / emotional weight** | (not a CLI flag) | enough texture to summarize the site intent — surfaced through the archetype probes (open-question discovery), not inferred |
-| **audience scope** | (drives `<<LOCALES>>`) | user explicitly stated: domestic (which country / region) OR international (which language[s]) |
-| **locales** | `<<LOCALES>>` | derived from audience scope; user nodded on the resulting BCP 47 list |
-| **description** | `<<DESCRIPTION>>` | agent-drafted in user's language; user nodded on the exact one-liner |
-| **summary** | `<<SUMMARY>>` | agent-drafted in user's language; user nodded on the exact one-liner |
-| **brand** | `<<BRAND>>` | you proposed 2–3 candidates (Brand stance, after purpose + audience texture is in); user picked one or supplied their own |
-| **project-name** | `<<PROJECT_NAME>>` | lowercase-hyphenated slug of brand; show the slug to user in the rehearsal (step 1) and confirm; user can override if they prefer a different repo / dir name |
-| **github owner** | `<<GITHUB_OWNER>>` | user explicitly stated their GitHub login (not derived from email) |
+| Value | Authorized when |
+|---|---|
+| **purpose / audience** | enough texture to summarize the site intent, not inferred |
+| **audience scope** | user explicitly stated domestic/international audience and languages |
+| **locales** | derived from audience scope; user nodded on the resulting BCP 47 list |
+| **description** | agent-drafted in user's language; user nodded on the exact one-liner |
+| **summary** | agent-drafted in user's language; user nodded on the exact one-liner |
+| **brand** | user picked one, supplied one, or accepted your proposal |
+| **project-name** | lowercase-hyphenated slug shown to user and confirmed |
+| **github owner** | user explicitly stated their GitHub login/org, not derived from email |
 
 If any value is unauthorized — including auto-derivation that "looks reasonable" — the work is still in the interview. Return there. Step 1 below IS the rehearsal back to the user in their language; it is not the moment you collect authorization for unfilled values.
 
 1. **Confirm the synthesized draft.** User accepts or corrects.
 
-2. **Run the composed `## Run this` block.** Scroll to the `## Run this` section at the bottom of this composed document — the landing composer baked the archetype, theme, and any preselected feature literals into the command. Copy it verbatim, fill the 6 `<<...>>` markers from your authorized interview values (see Prerequisites table above), and run it.
+2. **Run `create-mantle`.** Use the release tarball URL supplied by the
+   landing page, release notes, or Mantle starter docs. Fill flags only
+   from confirmed values:
 
-   Do not modify the literal flags or the archetype positional. Do not invent additional `--feature` flags from vibes; features must come from the composed command or an explicit user request. If a marker has no authorized value, you're still in the interview — return there.
+   ```bash
+   npx <create-mantle-tarball> <archetype> \
+     --project-name <project-name> \
+     --brand "<brand>" \
+     --description "<description>" \
+     --locales "<locale[,locale]>" \
+     --github-owner <github-owner> \
+     --admin-github-login <admin-login> \
+     --summary "<summary>" \
+     [--theme <theme>] \
+     [--feature <feature>]
+   ```
+
+   Do not invent `--theme` or `--feature` flags. They must come from
+   landing, a starter doc, or an explicit user request.
 
    The CLI fetches `sources.json` at runtime from the requested starter ref (`--ref` / `--starter-ref`; release commands should pin a tag or explicit ref), downloads the starters tarball, merges `_common/` + `<archetype>/` + selected feature overlays + (optional) `themes/<theme>/`, fills `{{PLACEHOLDER}}` macros, renames `.template` files, runs `git init` and `pnpm install`. RUN_NOTES JSON arrives on stdout, including `features` when overlays were selected.
 
@@ -256,14 +287,13 @@ If any value is unauthorized — including auto-derivation that "looks reasonabl
 
    When the public home route is empty/404, tell the user plainly: "the worker is running; the public homepage has no content yet." Then ask whether they want a **local preview seed** so they can see the homepage and, for post-shaped archetypes, a couple of sample posts in the browser. Do not run generic test fixtures or seed content without explicit consent. If they say yes, keep the seed preview-only and local: use user-approved copy from the interview or step 6 drafting, make it clear it is not production content, and do not commit local DB/KV artifacts or `.dev.vars`. If they say no, continue with the install flow; production content can be created later through `/admin` or MCP.
 
-6. **Write the deterministic `mantle/site.md` notes in your normal register.**
-
-   Keep this short and practical. The goal is to persist what the user authorized so the next agent is not guessing, not to finish brand prose before deploy.
+6. **Keep `mantle/site.md` deterministic.**
 
-   - `## site` — one paragraph reflecting why this site exists.
-   - `## voice` — a few honest register markers only when the user gave you real language or reactions. If voice did not surface, write short.
-   - `## history` — one paragraph: what was decided, what the user said in their words, and what's still open.
-   - `## editor first_prompt:` body — mechanical fill. Copy the archetype hint's `Editor first-prompt template` block, substitute `<<BRAND>>` with the actual brand, paste as plain text under the YAML `first_prompt: |` key (indented properly).
+   The scaffold already records the launch description and open
+   provision items. Do not block first deploy on polishing voice, welcome
+   copy, or editor prompts. If the user gave concrete notes, add a short
+   `## history` paragraph and validate. Otherwise leave content work for
+   the post-deploy coding/content agent.
 
 7. **Run deploy validation.**
 
@@ -275,7 +305,12 @@ If any value is unauthorized — including auto-derivation that "looks reasonabl
 
 8. **Commit.** If step 4 produced an adjustment, that's its own commit. Then the main commit: `mantle: deterministic scaffold`.
 
-9. **Continue to provision — don't push a URL onto the user.** Provision is the next phase in the same conversation. If you came from the fallback composed-prompt path, replace `install` with `provision` in the composed URL you read at the start, keep the same `?type=`, `?theme=`, and future `?feature=` query values, fetch that URL, follow it. If you came from launch-session path, read `.mantle/launch-state.json` for the GitHub owner/admin metadata, then fetch `https://raw.githubusercontent.com/aotter/mantle/develop/skills/provision/SKILL.md` unless the landing origin supplied a provision URL.
+9. **Continue to provision — don't push a URL onto the user.** Provision
+   is the next phase in the same conversation. Read
+   `.mantle/launch-state.json` for GitHub owner/admin metadata when it
+   exists, then use the repo-local `mantle:provision` skill generated
+   into the scaffold. If it is missing, fetch
+   `https://raw.githubusercontent.com/aotter/mantle/develop/skills/provision/SKILL.md`.
 
    The current provision shape is deterministic first: create/push the private GitHub repo, guide the user through Cloudflare's GitHub-backed first deploy, then use Wrangler to take over follow-up bindings/secrets/migrations. If GitHub CLI auth is invalid, the user's next involvement is re-auth first; after they reply that it is fixed, re-run `gh auth status` and then continue provision. Don't promise production-readiness until provision completes and a second agent connects through MCP.
 

package/skills/provision/SKILL.md

@@ -6,27 +6,27 @@ when_to_invoke: |
 applies_to: mantle@v0.1.0
 ---
 
-# Provision a mantle project
+# Provision a Mantle Project
 
 You're taking an installed consumer project from local files to a
 user-owned GitHub repo and Cloudflare Worker.
 
-The base flow is dashboard-first:
+The base flow is deterministic first, provider-browser second:
 
-1. The user's coding agent scaffolds and pushes a private GitHub repo.
-2. The user opens Cloudflare Dashboard and creates a Worker from that
-   GitHub repo. Cloudflare performs the first deploy and owns automatic
-   first-deploy resource provisioning for id-less bindings.
+1. The coding agent validates the scaffold and pushes a private GitHub
+   repo.
+2. The user creates the first Cloudflare Worker deploy from that GitHub
+   repo in Cloudflare Dashboard. Cloudflare owns automatic first-deploy
+   resource provisioning for id-less bindings.
 3. The user reports the deployed Worker URL back to the agent.
 4. The user creates the per-site GitHub OAuth App.
 5. The agent runs `pnpm run provision:up` to write non-secret config,
    set Worker secrets through Wrangler, and update local handoff files.
 
 Mantle landing is not the executor. It provides launch context and a
-complete handoff; provider authority stays with the user and their
-coding agent.
+handoff; provider authority stays with the user and their coding agent.
 
-## End state
+## End State
 
 - The scaffold is committed and pushed to the user's private GitHub repo.
 - Cloudflare has deployed the Worker from that repo at least once.
@@ -45,210 +45,98 @@ created after owner sign-in through Staff MCP / admin authoring.
 
 ## Principles
 
-1. **Use the user's accounts.** The repo belongs to the user's GitHub
+1. Use the user's accounts. The repo belongs to the user's GitHub
    account or org. The Worker belongs to the user's Cloudflare account.
-   Do not make Mantle a central runtime dependency.
-
-2. **No Cloudflare API token in the base flow.** The base provision path
-   does not ask for `CLOUDFLARE_API_TOKEN` and does not call Cloudflare
-   resource APIs directly. Cloudflare Dashboard + Workers Builds handle
-   the first deploy; Wrangler handles secrets after the user logs in.
-
-3. **GitHub OAuth is per-site and user-owned.** The user creates a
-   GitHub OAuth App for this generated site. The exact callback URL is:
-   `<worker-url>/api/auth/callback/github`
-
-4. **Same GitHub login for admin.** `gh auth status`, the OAuth App
-   owner, and `ADMIN_GITHUB_LOGIN` should line up unless the user
-   intentionally chose an org repo with a separate admin login.
-
-5. **Launch state is context, not provider authority.** If install came
-   from Mantle landing, read `.mantle/launch-state.json`. It can supply
-   owner, admin login, repo name, locales, archetype, theme, and
-   selected features. It does not authorize Cloudflare operations,
+2. Do not ask for a Cloudflare API token in the base flow. Cloudflare
+   Dashboard plus Workers Builds handle the first deploy; Wrangler
+   handles secrets after the user logs in.
+3. GitHub OAuth is per-site and user-owned. The callback URL is exactly
+   `<worker-url>/api/auth/callback/github`.
+4. Launch state is context, not provider authority. `.mantle/launch-state.json`
+   may supply owner, admin login, repo name, locales, archetype, theme,
+   and selected features. It does not authorize Cloudflare operations,
    billing-gated features, OAuth secrets, or custom domains.
+5. `BETTER_AUTH_SECRET` is load-bearing. Preserve an existing secret;
+   rotating it invalidates sessions.
 
-6. **Feature overlays can add optional provider steps.** Read
-   `.mantle/features.json` before provision. For example, `media-r2`
-   may ask the operator to make an explicit R2/billing choice after the
-   base site is online.
-
-7. **`BETTER_AUTH_SECRET` is load-bearing.** The shared provision runner
-   leaves an existing `BETTER_AUTH_SECRET` in place and creates one only
-   when missing. Rotating it invalidates sessions and may make stored
-   JWK rows unreadable. Do not rotate casually.
+## Flow
 
-## CLI surface
+Run from the generated project root.
 
-Run from the generated project root:
+1. Preflight:
 
 ```bash
+pnpm install --frozen-lockfile
 pnpm validate
 pnpm typecheck
-pnpm run provision:plan
-pnpm exec wrangler login
-pnpm run provision:up -- --worker-url <worker-url> --github-username <gh-login> --client-id <client-id>
+if node -e "process.exit(require('./package.json').scripts?.test ? 0 : 1)"; then
+  pnpm test
+else
+  echo "No pnpm test script; skipping."
+fi
+git status --short
+gh auth status
 ```
 
-`provision:plan` is read-only. It prints the Cloudflare dashboard
-first-deploy steps, the GitHub OAuth App fields, the Wrangler login
-requirement, and feature-specific notes.
-
-`provision:up` requires:
+If GitHub CLI auth is missing or points at the wrong login, pause and
+ask the user to switch/login before creating the repo.
 
-- `--worker-url <worker-url>`: the deployed Cloudflare Worker URL.
-- `--github-username <gh-login>`: the bootstrap admin GitHub login.
-- `--client-id <client-id>`: GitHub OAuth App Client ID.
-- `GITHUB_CLIENT_SECRET` in the environment or stdin.
+2. Create a private GitHub repo in the selected owner, add the remote,
+   commit the scaffold, and push. Use the user's GitHub auth context.
 
-It writes non-secret config, sets Worker secrets with Wrangler, updates
-`mantle/site.md` and `AGENTS.md`, then prints public/admin/MCP and
-operator setup URLs.
+3. Hand the user directly to Cloudflare's Git import path:
 
-Do not pass `GITHUB_CLIENT_SECRET` as a visible command argument.
-
-```bash
-read -rsp "GitHub OAuth client secret: " GITHUB_CLIENT_SECRET && export GITHUB_CLIENT_SECRET && printf "\n"
-pnpm run provision:up -- --worker-url <worker-url> --github-username <gh-login> --client-id <client-id>
+```text
+https://dash.cloudflare.com/?to=%2F%3Aaccount%2Fworkers-and-pages
 ```
 
-## Presenting browser steps (non-coder handoff)
-
-Flow steps 3 and 5 hand the user into a browser. That user is usually a
-non-coder who is trusting the agent — present those steps the way you'd
-guide someone over the phone, not as a terse engineer checklist. The
-plan that `provision:plan` prints is *your* reference; re-present it, do
-not paste it through.
-
-Rules:
-
-- **One task at a time.** Send the Cloudflare deploy, wait for the URL,
-  *then* send the GitHub OAuth App. Never dump both browser tasks in one
-  message.
-- **Number only what they see.** Label the block `STEP 1 of 2` /
-  `STEP 2 of 2`. Do not leak your internal plan numbering — a user
-  seeing "Step 2" and "Step 4" with gaps assumes they missed something.
-- **Lead with one plain "why".** A single sentence on what the step
-  accomplishes ("this is what puts your site on the internet").
-- **Full-sentence click paths, not arrows.** "Click *Create
-  application*, then open the *Import a repository* tab" — not
-  `Create application → Import a repository`. Quote the exact labels the
-  user sees on screen.
-- **Say what they'll see and what to copy.** Name the landmark and the
-  success signal ("a link ending in `.workers.dev` — copy that"), and a
-  rough time ("about a minute").
-- **Ask for values in plain language.** "Paste me the live link, and
-  the Client ID." Never ask for `KEY=value` shell syntax, and never make
-  them type literal `<...>` placeholders.
-- **Protect the secret in words, not jargon.** Tell them to copy the
-  Client Secret and keep it on their clipboard, and that you'll ask for
-  it privately so it never lands in the chat. Don't say "stdin" or "env".
-- **Give an escape hatch.** "If a screen doesn't match what I describe,
-  paste a screenshot and I'll point you to the right button."
-
-Keep agent-internal correctness rules out of the user-facing text. The
-`localhost` / `127.0.0.1` callback rule (see Don't) governs what *you*
-write; a dashboard user is handed the real Worker URL and never needs to
-hear that warning.
-
-## Flow
-
-1. **Preflight.** Read `.mantle/launch-state.json` if present, then
-   confirm the expected repo owner/admin login. Run:
-
-   ```bash
-   pnpm install --frozen-lockfile
-   pnpm validate
-   pnpm typecheck
-   git status --short
-   gh auth status
-   ```
+Ask them to create a Worker from the pushed GitHub repo, keep the Worker
+name equal to `wrangler.toml` `name`, wait for deploy, and send back the
+live `*.workers.dev` URL.
 
-   If GitHub CLI auth is missing or points at the wrong login, pause
-   and ask the user to switch/login before creating the repo.
+4. Print the deterministic plan:
 
-2. **Push the repo.** Create a private GitHub repo in the selected
-   owner, add the remote, commit the scaffold, and push. Use the user's
-   GitHub auth context.
-
-3. **Ask the user to run Cloudflare first deploy.** They should open
-   Cloudflare Dashboard, create a Worker, choose GitHub as source, pick
-   the repo, keep the Worker name aligned with the repo/project name,
-   and run the first deploy. They report the deployed Worker URL back.
-   Present this as `STEP 1 of 2` per **Presenting browser steps** above,
-   and wait for the Worker URL before moving on.
-
-4. **Print the plan.**
-
-   ```bash
-   pnpm run provision:plan
-   ```
-
-   Read any feature-specific notes out loud. If the project uses queues
-   or another Cloudflare resource that Dashboard cannot infer, follow
-   the plan's explicit instructions.
-
-5. **Create the GitHub OAuth App.** Ask the user to create it under the
-   account/org that should own site auth:
-
-   - Application name: project/site name
-   - Homepage URL: `<worker-url>`
-   - Authorization callback URL:
-     `<worker-url>/api/auth/callback/github`
-   - Device Flow: unchecked
-
-   Present this as `STEP 2 of 2` per **Presenting browser steps** above.
-   Ask for the Client ID in chat; have them keep the Client Secret on
-   the clipboard for the hidden prompt in step 6 — do not ask them to
-   paste the secret in chat.
-
-6. **Authorize Wrangler and run provision.**
+```bash
+pnpm run provision:plan
+```
 
-   ```bash
-   pnpm exec wrangler login
-   read -rsp "GitHub OAuth client secret: " GITHUB_CLIENT_SECRET && export GITHUB_CLIENT_SECRET && printf "\n"
-   pnpm run provision:up -- --worker-url <worker-url> --github-username <gh-login> --client-id <client-id>
-   unset GITHUB_CLIENT_SECRET
-   ```
+Read only the values needed for the current project. Do not dump
+internal notes or placeholder syntax onto a non-coder.
 
-7. **Commit provision outputs.** Confirm and commit local changes:
+5. Ask the user to create the per-site GitHub OAuth App after the Worker
+   URL is known:
 
-   ```bash
-   git status --short -- wrangler.toml src/mantleConfig.ts mantle/site.md AGENTS.md
-   ```
+- Homepage URL: `<worker-url>`
+- Authorization callback URL: `<worker-url>/api/auth/callback/github`
+- Device Flow: unchecked
 
-8. **Smoke test.**
+Ask for the Client ID in chat. Keep the Client Secret out of chat and
+pass it through the hidden shell prompt below.
 
-   ```bash
-   BASE='<worker-url>'
-   curl -s -o /dev/null -w '%{http_code}\n' "$BASE/mcp"                # unauthenticated should reject
-   curl -s -o /dev/null -w '%{http_code}\n' "$BASE/"                   # redirect or 200
-   curl -s -o /dev/null -w '%{http_code}\n' "$BASE/admin/sign-in"      # 200/302 auth entry
-   ```
+6. Authorize Wrangler and apply provision:
 
-   Then ask the user to sign in through GitHub at
-   `<worker-url>/admin/sign-in` and connect an MCP-capable client to
-   `<worker-url>/mcp/staff`.
+```bash
+pnpm exec wrangler login
+read -rsp "GitHub OAuth client secret: " GITHUB_CLIENT_SECRET && export GITHUB_CLIENT_SECRET && printf "\n"
+pnpm run provision:up -- --worker-url <worker-url> --github-username <gh-login> --client-id <client-id>
+unset GITHUB_CLIENT_SECRET
+```
 
-9. **Operator setup proof.** Open the operator setup URL:
+7. Commit and push generated non-secret outputs:
 
-   ```text
-   https://mantle.tools/connect?site=<url-encoded-worker-url>
-   ```
+```bash
+git status --short -- wrangler.toml src/mantleConfig.ts mantle/site.md AGENTS.md
+```
 
-   Confirm it shows the Staff MCP URL, User MCP URL, Claude connector
-   entry, and `mantle-companion-upload` plugin install commands. The
-   companion upload path must pass file references/metadata only; large
-   binary payloads go through Mantle upload sessions and signed URLs,
-   not base64 MCP tool arguments.
+8. Smoke test:
 
-10. **Second-agent proof.** Connect a second agent through Staff MCP and
-   run the starter's core workflow: list collections, create/update a
-   draft, publish or submit the starter's natural operation, and confirm
-   a public read path. Do not create throwaway production submissions
-   unless the user explicitly accepts those records.
+- public home route;
+- `/admin/sign-in`;
+- GitHub admin sign-in;
+- `/mcp/staff` with an agent client when available;
+- a starter-specific core workflow.
 
-## Feature overlays
+## Feature Overlays
 
 If `.mantle/features.json` lists features, run the repo-local feature
 overlay skill first:
@@ -257,25 +145,24 @@ overlay skill first:
 .agent/skills/mantle-feature-overlays/SKILL.md
 ```
 
-Feature scripts are starter lifecycle scripts, not Mantle CLI
-commands. Run them only when the feature is present and the user
-accepts any extra provider/billing requirement.
+Feature scripts are starter lifecycle scripts, not Mantle CLI commands.
+Run them only when the feature is present and the user accepts any extra
+provider/billing requirement.
 
 ## Handoff
 
 After smoke checks pass, render a short final handoff in the user's
-language, in plain words (no `wrangler.toml` / secret / CLI jargon):
+language:
 
 - Public URL.
 - Admin sign-in URL.
 - Staff MCP URL.
-- Operator setup URL (`https://mantle.tools/connect?site=...`) for
-  Staff/User MCP connection and the companion upload plugin.
+- Operator setup URL (`https://mantle.tools/connect?site=...`).
 - What changed locally and what was committed.
 - Any intentionally deferred feature setup.
 
-Point future agents at `mantle/site.md`, `AGENTS.md`, and the
-repo-local `.agent/skills/` directory.
+Point future agents at `mantle/site.md`, `AGENTS.md`, and the repo-local
+`.agent/skills/` directory.
 
 ## Diagnostics
 
@@ -297,7 +184,3 @@ repo-local `.agent/skills/` directory.
   locally and the real Worker URL in production.
 - Don't use `/admin/auth/github/callback`; the Better Auth callback path
   is `/api/auth/callback/github`.
-- Don't recite a browser step to a non-coder as a terse `A → B → C`
-  breadcrumb, a `KEY=value` reply contract, a `<placeholder>` they might
-  paste literally, or an internal correctness warning (e.g. the
-  `127.0.0.1` rule). See **Presenting browser steps**.

package/docs/prompts/README.md

@@ -1,55 +0,0 @@
-# Starting prompts
-
-Localized two-URL starting-prompt drafts, one per archetype + locale.
-
-## What these are
-
-The single sentence the user pastes into Claude Code / Cursor / Codex / any MCP-capable agent to bootstrap a new mantle project. Format is always:
-
-```
-<localized verb> <SKILL_INSTALL_URL> <localized connector> <SKILL_ARCHETYPE_URL> <localized "for this purpose">: <Archetype name>.
-```
-
-Two URLs, no YAML, no form fields. The skill reads both URLs, then [Mantle](../../skills/install/SKILL.md) conducts a soft conversation to gather the rest. The official landing page at the Mantle landing page (source: [`aotter/mantle-landing`](https://github.com/aotter/mantle-landing)) generates this string dynamically from `src/starterArchetypes.ts` — the files in this directory are direct-paste fallbacks and references for documentation.
-
-## File naming
-
-```
-docs/prompts/<archetype>.<locale>.md
-```
-
-- `<archetype>` matches a file in [`skills/install/archetypes/`](../../skills/install/archetypes/).
-- `<locale>` follows BCP 47. The locale of the prompt only affects the verb / connector phrasing; the site's canonical locale is set later through Mantle's interview.
-
-## URL convention
-
-- `SKILL_INSTALL_URL` = `https://raw.githubusercontent.com/aotter/mantle/<ref>/skills/install/SKILL.md`
-- `SKILL_ARCHETYPE_URL` = `https://raw.githubusercontent.com/aotter/mantle/<ref>/skills/install/archetypes/<archetype>.md`
-
-`<ref>` is a pinned release tag (preferred) or `main`. The landing page uses the pinned tag.
-
-## What the prompt does NOT carry
-
-These used to live in a `mantle_request:` YAML block. They are now gathered by Mantle's interview:
-
-- `project_name`
-- `brand`
-- `description`
-- `github_username`
-- `locales`
-
-The Mantle thesis says the runtime carries complexity — Mantle, here, gathers what install needs without a pre-flight form.
-
-## Adding a prompt
-
-When a new archetype lands in [`skills/install/archetypes/`](../../skills/install/archetypes/):
-
-1. Add `docs/prompts/<archetype>.<locale>.md` for each supported locale.
-2. Update `mantle-landing/src/starterArchetypes.ts` `promptEn` / `promptZh` for the same archetype.
-3. Keep the format consistent across locales — only the verb / connector localize.
-
-## See also
-
-- [Epic #97](https://github.com/aotter/mantle/issues/97) — landing-page-prompt no-YAML pivot.
-- [`skills/install/SKILL.md`](../../skills/install/SKILL.md) — what the agent does after receiving the prompt.
-- [ADR-0013](../adr/0013-agent-provisioned-consumer-projects.md) — the broader install / provision / handoff flow.

package/docs/prompts/publication.en.md

@@ -1 +0,0 @@
-Use https://raw.githubusercontent.com/aotter/mantle/{template_ref}/skills/install/SKILL.md and https://raw.githubusercontent.com/aotter/mantle/{template_ref}/skills/install/archetypes/publication.md to build: Publication.

package/docs/prompts/publication.zh-TW.md

@@ -1 +0,0 @@
-用 https://raw.githubusercontent.com/aotter/mantle/{template_ref}/skills/install/SKILL.md 跟 https://raw.githubusercontent.com/aotter/mantle/{template_ref}/skills/install/archetypes/publication.md 架設：Publication 網站。