@aotter/mantle 0.0.11-alpha.24 → 0.0.11-alpha.26

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/docs/adr/0016-site-semantic-layer.md

@@ -2,7 +2,7 @@
 
 ## Status
 
-Accepted (slimmed 2026-05-12 per Epic #116; original 2026-05-12).
+Accepted (slimmed 2026-05-12 per Epic #116; letter surface suspended 2026-06-19).
 
 ## Decision
 
@@ -11,12 +11,14 @@ Every agent-authored mantle project carries two files at fixed paths. They serve
 | File | Audience | Size budget | Format |
 |---|---|---|---|
 | `AGENTS.md` | Any cross-tool agent harness (Codex / Cursor / Aider / Amp / Factory / Claude Code) | ~30 lines | Plain markdown |
-| `mantle/site.md` | Mantle (install / customize / deploy persona — Epic #47, scoped per Epic #116) | ~300 lines | Frontmatter + section bodies |
+| `mantle/site.md` | Mantle install / customize / deploy context | ~300 lines | Frontmatter + section bodies |
 
 `AGENTS.md` answers "what is this and how do I run it." `mantle/site.md` carries the site's semantic layer:
 
 - Frontmatter: machine-readable (`archetype`, `brand`, `locales`, `site_url`, `revisions[]`, `futures[]`, `dont_touch[]`).
-- Body sections (`## site`, `## voice`, `## welcome` (5 cards), `## editor`, `## history`) each open with a `> purpose:` header so agents can route reads without parsing prose. Mantle reads the whole file on return, edits sections, writes the whole file back. **Atomic replace, not append.**
+- Body sections (`## site`, `## voice`, `## editor`, `## history`) each open with a `> purpose:` header so agents can route reads without parsing prose. Mantle reads the whole file on return, edits sections, writes the whole file back. **Atomic replace, not append.**
+
+The earlier `## welcome` 5-card letter surface is suspended. Provisioning must not block on prose completion in `mantle/site.md`; a first deploy should be possible from deterministic scaffold state.
 
 ## Placeholder macros
 
@@ -38,7 +40,7 @@ New macros must be added here, to `_common/*.template`, and to the substitution
 
 ## Update rules
 
-- **Mantle on return**: read whole `mantle/site.md`, edit relevant sections, write whole atomically, append one paragraph to `## history`. Voice rules (Epic #116 scope-narrow) apply only when editing the `## welcome` 5 cards and the closing handoff line.
+- **Mantle on return**: read whole `mantle/site.md`, edit relevant sections, write whole atomically, append one paragraph to `## history`.
 - **provision on deploy**: rewrite frontmatter `site_url:` placeholder → real Workers URL; append a `revisions:` entry. Same `Public site:` rewrite in `AGENTS.md`. Single commit at end of provision.
 - **No mid-section staged-and-running mutation.** A section is prose-replaced atomically, or a frontmatter scalar/list is replaced — never partial writes.
 
@@ -50,6 +52,6 @@ New macros must be added here, to `_common/*.template`, and to the substitution
 
 - Templates: `mantle-starters/_common/AGENTS.md.template` and `mantle-starters/_common/mantle/site.md.template`.
 - Substitution: `packages/create-mantle/src/placeholder.ts`.
-- Install handoff: `skills/install/SKILL.md` describes the post-substitution prose-fill (HTML comments → prose drawn from interview).
+- Install handoff: `skills/install/SKILL.md` describes deterministic scaffold validation and the short post-substitution notes fill.
 - Provision update: `skills/provision/SKILL.md` describes the `site_url:` + `revisions:` write after deploy.
 - Theme overlay merge (Epic #116): `themes/<theme-key>/` overlay applies after the archetype starter and may touch `src/theme/` — never these two files.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aotter/mantle",
-  "version": "0.0.11-alpha.24",
+  "version": "0.0.11-alpha.26",
   "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-cloudflare": "0.0.11-alpha.24",
-    "@aotter/mantle-runtime": "0.0.11-alpha.24",
-    "@aotter/mantle-admin-ui": "0.0.11-alpha.24",
-    "@aotter/mantle-spec": "0.0.11-alpha.24"
+    "@aotter/mantle-admin-ui": "0.0.11-alpha.26",
+    "@aotter/mantle-runtime": "0.0.11-alpha.26",
+    "@aotter/mantle-spec": "0.0.11-alpha.26",
+    "@aotter/mantle-cloudflare": "0.0.11-alpha.26"
   },
   "peerDependencies": {
     "@cloudflare/workers-oauth-provider": "^0.7.0",
@@ -63,7 +63,7 @@
     "@cloudflare/workers-oauth-provider": "^0.7.0",
     "@types/node": "^25",
     "aws4fetch": "^1.0.20",
-    "better-auth": "^1.6.11",
+    "better-auth": "^1.6.14",
     "hono": "^4.12.23",
     "typescript": "^6.0.3",
     "zod": "^4.4.2"

package/skills/install/SKILL.md

@@ -1,13 +1,17 @@
 ---
 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 delegates the Mantle welcome letter to a background subagent. 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. Do not switch to the retired prompt-composition
+flow.
 
 ## Ground truth
 
@@ -41,8 +45,7 @@ pnpm introspect       # current manifest dump (atoms inventory)
 pnpm emit-openapi     # generated HTTP surface
 pnpm emit-types       # generated TS types
 pnpm validate         # grammar + cross-ref check (preview phase by default).
-                      # For the pre-deploy gate (re-enables MANTLE_LETTER_NOT_WRITTEN
-                      # and any future production-only checks), use
+                      # For production-only checks, use
                       # `pnpm validate --phase deploy` or `pnpm validate:deploy`.
 ```
 
@@ -95,7 +98,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:
 
@@ -112,13 +115,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
 
@@ -126,22 +133,25 @@ Listed in discovery order — purpose comes first, brand near the end. **Do not
 
 | Value | For |
 |---|---|
-| **purpose / audience / emotional weight** | Mantle subagent — surfaces through the archetype probes; feeds the welcome letter |
+| **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)
 
@@ -191,46 +201,67 @@ Invoking the `create-mantle` release tarball is **not low-risk work**. The comma
 
 - every page's SEO `<meta description>`
 - locale routing for the entire site (canonical + redirects)
-- Mantle's welcome-card surface in `## welcome`
+- the persistent site notes in `mantle/site.md`
 - 22 starter files' `{{PLACEHOLDER}}` substitution
 - `revisions[0]` — the permanent install-moment entry in the changelog
 
 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** | (feeds Mantle, not a CLI flag) | enough texture for Mantle's letter — 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.
 
 3. **Read the RUN_NOTES.** The `files_written` list is your scaffold inventory. If `features` is non-empty, read `.mantle/features.json` and the generated `src/.mantle/generated.*.ts` glue before deciding anything else. Walk the ground-truth files — at minimum `manifests/`, `src/mantleConfig.ts`, `mantle/site.md` — before deciding anything else.
 
-4. **Adjustment window** (optional, see § below). Only if the interview surfaced a concrete deletion or single-field gap. Always `pnpm validate` after edit; commit before the Mantle subagent runs.
+4. **Adjustment window** (optional, see § below). Only if the interview surfaced a concrete deletion or single-field gap. Always `pnpm validate` after edit.
 
 5. **Validate locally:**
 
@@ -239,9 +270,9 @@ If any value is unauthorized — including auto-derivation that "looks reasonabl
    pnpm typecheck
    ```
 
-   `pnpm validate` runs in the **preview phase** by default — grammar + cross-Schema checks only. `MANTLE_LETTER_NOT_WRITTEN` is silenced here on purpose (it's a deploy-only gate), so this step is expected to exit 0 on a fresh scaffold. Anything non-zero → surface `code` + `suggestion` verbatim.
+   `pnpm validate` runs in the **preview phase** by default — grammar + cross-Schema checks only. Anything non-zero → surface `code` + `suggestion` verbatim.
 
-   The deploy-phase variant (`pnpm validate --phase deploy`, or `pnpm validate:deploy` if the starter ships that script) re-enables `MANTLE_LETTER_NOT_WRITTEN`; provision runs that before `wrangler deploy`. Until step 9 fills the welcome letter cards, deploy-phase will fail — that's the intended sequencing.
+   The deploy-phase variant (`pnpm validate --phase deploy`, or `pnpm validate:deploy` if the starter ships that script) is safe to run on a fresh scaffold. It must not block on unfinished prose in `mantle/site.md`.
 
    **Then set up `.dev.vars` so `pnpm dev` works.** Starters that ship `.dev.vars.example` (publication / transaction / intake / presence) require a real `BETTER_AUTH_SECRET` before `pnpm dev` — the worker returns `auth_not_configured` on every request until it's filled. Copy the file, generate a value, and write it in:
 
@@ -257,56 +288,36 @@ 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. **Pre-provision dialogue — preview + voice elicitation (this is a chatter zone, not a checklist).**
-
-   Before writing `mantle/site.md` prose or dispatching the Mantle subagent, open a small conversation with the user. The goals are (a) let them peek at what just got built, (b) **draw voice material out of them by writing something concrete together** rather than asking abstract "what's your register" questions.
-
-   Read RUN_NOTES `files_written` to see which collections the archetype actually ships. The drafting medium depends on what's there:
-
-   - **Archetypes with a post-like collection** (`publication`, `community`, `membership`): offer to draft 1–2 sample posts/entries. Propose 2–4 topics anchored in what the interview surfaced (training log, a parenting moment, a brand-voice opener, etc.). Let the user pick, add, kill. Drafts get saved to `mantle/drafts/<slug>.md`; admin can pick them up later.
-   - **Archetypes without posts** (`presence`, `intake`, `transaction`, `reservation`, `blank`): no `posts` collection exists — **do not fabricate one**. Instead, offer to draft one short concrete piece of copy the archetype actually needs: the home-page opening sentence, the intake form intro, the reservation page tagline. One paragraph max. Save into `mantle/drafts/home-opener.md` (or similar archetype-fitting name) only if the user wants it kept.
-   - **Roadmap archetypes**: skip this step entirely. The refuse path already routed the conversation.
+6. **Keep `mantle/site.md` deterministic.**
 
-   For any drafting that happens, the dynamic is the same: show the user, let them react, capture the reactions. Each correction / line cut / tone push / pronoun-choice complaint is gold for voice elicitation.
+   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.
 
-   For cover images (post-shaped drafts only): use LoremFlickr (`source.unsplash.com` was deprecated in 2023; LoremFlickr is the closest keyword-based replacement). Pick 1–3 comma-separated keywords from the draft content. URL pattern: `https://loremflickr.com/<width>/<height>/<keyword1>,<keyword2>`. **Verify each URL resolves with a GET request before embedding — expect a 302 redirect to a cached JPG (`curl -sL -o /dev/null -w "%{http_code} %{content_type}"`), and confirm final status is 200 and content-type starts with `image/`.** Don't use `HEAD` — LoremFlickr's resized-cache path responds to GET only. If verification fails, leave the cover slot empty and tell the user.
-
-   This step's length is responsive to the user. Curt user / no-deadline / "just go" → keep it to one offer and skip on a no. Engaged user → spend 5–10 minutes drafting together. The investment here pays off in the next step.
-
-7. **Write the non-letter `mantle/site.md` sections + the editor `first_prompt:` body in your normal register.**
-
-   You fill these — Mantle (the subagent in step 9) only owns the welcome letter cards. Use what came out of the interview + step 6's drafting dialogue. **Reflect what the user said and how they reacted.** Imagination is fine where the user left blank space; don't fabricate vocabulary they pushed back on or never used.
-
-   - `## site` — one paragraph reflecting why this site exists.
-   - `## voice` — a few lines of register markers, with priority on phrases the user actually used / words they killed during drafting / titles they liked vs hated. If voice didn't surface concretely, write SHORT; honest brevity beats invented detail.
-   - `## history` — one paragraph: what was decided, what the user said in their words, what's still open. Note any emotional weight (excited / anxious / curt / grieving). If you drafted posts in step 6, mention the drafts + how user reacted — Mantle reads this as transcript material.
-   - `## 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).
-
-8. **Get the Mantle subagent prompt:**
+7. **Run deploy validation.**
 
    ```bash
-   pnpm -s mantle:prompt > /tmp/mantle-letter-prompt.md
+   pnpm validate:deploy
    ```
 
-   `-s` suppresses pnpm's banner so the file is just the prompt body. The script reads `mantle/site.md` (frontmatter + your `## site` / `## voice` / `## history` sections), fetches the archetype hint from `mantle-starters`, substitutes `<<MANTLE_*>>` placeholders in the scaffolded `mantle-subagent-prompt.md`, prints to stdout. Fails fast if any of the three sections still hold template placeholders.
-
-9. **Dispatch the Mantle subagent (in background)** with `/tmp/mantle-letter-prompt.md` as its only prompt body. Use a `general-purpose` subagent with `run_in_background: true`.
-
-   The subagent writes **three welcome cards** (card1 with Mantle's self-intro + a noticed detail; card4 — when you need me back; card5 — done + closing line) plus the closing handoff line at the end of `## welcome`. Cards 2 (mcp install command) and 3 (editor first prompt) are mechanical — admin UI renders them at display time from `<SITE_URL>`, the brand, and your filled `## editor first_prompt:`. They don't live in `mantle/site.md`.
-
-   **You stay in your normal register throughout.** You never write the welcome letter yourself; Mantle's voice is encapsulated in the subagent prompt template that `pnpm mantle:prompt` filled. This is the whole reason for the delegation — register isolation. Don't peek-and-confirm the cards before they're written; the letter is a small surprise the user discovers in `mantle/site.md`.
-
-   While the subagent works, prepare provision context: `gh auth status`, confirm the GitHub identity from the interview matches. If `gh auth status` reports an invalid token, missing login, or the wrong GitHub account, do not end with a bare "run `gh auth login`" instruction. Say that install is complete and provision is blocked only on GitHub re-auth, tell the user exactly which login is expected, ask them to run `gh auth login -h github.com` (or switch accounts) and reply when done, then resume from provision preflight in the same conversation.
+   If the project only exposes the CLI command, run `pnpm validate --phase deploy`. This is the readiness gate before handing off to provision.
 
-10. **When the Mantle subagent returns**, run `pnpm validate --phase deploy` (or `pnpm validate:deploy` if the starter ships that script) — `MANTLE_LETTER_NOT_WRITTEN` should now clear, since the cards are filled. If it still fires, card1 / card4 / card5 weren't all written; check the subagent's reply for what went wrong, fix or re-dispatch. This is also the readiness gate before handing off to provision.
+8. **Commit.** If step 4 produced an adjustment, that's its own commit. Then the main commit: `mantle: deterministic scaffold`.
 
-11. **Commit.** If step 4 produced an adjustment, that's its own commit. Then the main commit: `mantle: notes from install interview`.
+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`.
 
-12. **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. The user's next involvement is supplying the Cloudflare API token when provision asks — everything before that is your job. 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.
+   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.
 
 ## Adjustment window — between scaffold and provision
 
-A permitted modification turn after `create-mantle` returns and before the Mantle subagent fires. Small concrete edits to match what the user said.
+A permitted modification turn after `create-mantle` returns and before provision starts. Small concrete edits to match what the user said.
 
 ### In scope
 
@@ -327,13 +338,12 @@ A permitted modification turn after `create-mantle` returns and before the Mantl
 
 ### Discipline
 
-- `pnpm validate` after every edit. Non-clean tree never advances to the Mantle subagent.
+- `pnpm validate` after every edit. Non-clean tree never advances to provision.
 - Show the diff before applying. A deleted manifest deserves a one-line confirm.
 - Don't speculate. "I think you might also want X" is generation, not interview.
 
 ## Don't
 
-- Don't put on Mantle's voice yourself — that's the subagent's job. Register isolation is the whole point of the delegation in step 9.
 - Don't write into `src/theme.default/` or any "system-looking" path during install — design changes happen after deploy via the customize-design skill.
 - Don't keep speaking after the handoff to provision — the handoff IS the end of this Skill.
-- Don't echo the same specific user detail across multiple cards (that's Mantle's rule, but you also shouldn't paste card1's detail back into `## site` — let each section have its own).
+- Don't echo the same specific user detail across every generated note — let each section have its own job.

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 網站。