@looop-games/cli 0.1.5 → 0.1.7

package/lib/agent-surface.mjs

@@ -0,0 +1,294 @@
+// The agent surface — skills + the Layer-0 managed block — and how an update
+// reaches a repo that already exists (creator-harness Slice 2, decision Q2).
+//
+// The surface ships INSIDE the versioned engine artifact, not the npm CLI: the
+// CLI's template is only a create-time SEED (the engine is login-gated, so a
+// fresh folder can't download one before its first `dev`). From then on the
+// artifact is the source of truth. Without this, a creator's skills are frozen
+// at the version they created the game with — the exact freeze Q2 exists to end.
+//
+// **This runs ONLY under `looop update`** (2026-07-11) — never on `dev`
+// or `publish`. It COULD run there safely (it can only ever converge a repo to
+// the engine version already pinned in its package.json, never a newer one),
+// but a creator who ran `dev` and then found files they never wrote sitting in
+// `git status` would be right to feel we'd gone through their pockets. Updates
+// are something you ASK for. So this module writes nothing on its own schedule,
+// and it narrates nothing either: it returns what it did, and `looop update`
+// tells the creator, who decides whether to commit it.
+//
+// The one contract everything here serves:
+//
+//     an update reaches a pre-existing repo without touching anything
+//     user-owned.
+//
+// So ownership is tracked explicitly, in `.looop/agent-surface.json` — the
+// hash of every file WE wrote. On each run a file is one of:
+//
+//   ours, unmodified  (hash matches what we recorded)  → replace with the new
+//   ours, edited      (hash differs)                   → KEEP theirs, warn
+//   never ours        (no record, but on disk)         → KEEP theirs, warn
+//   not on disk                                        → place ours
+//   retired upstream                                   → remove, if still ours
+//
+// A skill we never placed is never even enumerated, so a creator's own skills
+// are invisible to this code by construction. `AGENTS.md` is the exception that
+// proves the rule: the managed block between the markers is ours to rewrite;
+// everything outside them (their title, their instructions below the end
+// marker) is theirs and is spliced back untouched.
+import { createHash } from 'node:crypto';
+import { cpSync, existsSync, mkdirSync, readFileSync, readdirSync, rmSync, statSync, writeFileSync } from 'node:fs';
+import { dirname, join } from 'node:path';
+
+export const SURFACE_DIR = 'agent-surface';
+export const LOCAL_MANIFEST = '.looop/agent-surface.json';
+
+const START = '<!-- looop:managed:start -->';
+const END = '<!-- looop:managed:end -->';
+
+const sha = (buf) => createHash('sha256').update(buf).digest('hex');
+
+// Where each artifact path lands in the game repo. `skills/**` is the whole
+// surface today; AGENTS.md is spliced rather than written whole.
+function target(rel) {
+  if (rel === 'AGENTS.md') return 'AGENTS.md';
+  if (rel.startsWith('skills/')) return join('.claude', rel);
+  return null; // unknown surface entry from a newer engine — ignore, don't guess
+}
+
+function projectName(projectDir) {
+  try {
+    return JSON.parse(readFileSync(join(projectDir, 'package.json'), 'utf8')).name || '';
+  } catch {
+    return '';
+  }
+}
+
+function readLocal(projectDir) {
+  try {
+    const m = JSON.parse(readFileSync(join(projectDir, LOCAL_MANIFEST), 'utf8'));
+    return { engineVersion: m.engineVersion ?? null, placed: m.placed ?? {} };
+  } catch {
+    return null; // no manifest = a pre-Slice-2 repo; see `adopt` below
+  }
+}
+
+function writeLocal(projectDir, engineVersion, placed) {
+  const p = join(projectDir, LOCAL_MANIFEST);
+  mkdirSync(dirname(p), { recursive: true });
+  writeFileSync(p, JSON.stringify({ engineVersion, placed }, null, 2) + '\n');
+}
+
+// Removing the last SKILL.md from a skill folder must remove the folder too —
+// an empty `.claude/skills/handbook/` still reads to an agent as a skill that
+// exists and is broken. Walks up, stopping at .claude/skills (never the repo).
+function pruneEmptyDirs(projectDir, dest) {
+  let dir = dirname(join(projectDir, dest));
+  const stop = join(projectDir, '.claude', 'skills');
+  while (dir.startsWith(stop) && dir !== stop) {
+    try {
+      if (readdirSync(dir).length) return;
+      rmSync(dir, { recursive: true, force: true });
+    } catch {
+      return;
+    }
+    dir = dirname(dir);
+  }
+}
+
+// Splice the artifact's managed block into the repo's AGENTS.md, preserving
+// everything outside the markers. Returns null when the creator's file has no
+// markers — they rewrote Layer 0 themselves, so it is theirs now.
+function spliceManaged(current, incoming) {
+  const cs = current.indexOf(START);
+  const ce = current.indexOf(END);
+  if (cs === -1 || ce === -1 || ce < cs) return null;
+
+  const is = incoming.indexOf(START);
+  const ie = incoming.indexOf(END);
+  if (is === -1 || ie === -1) return null;
+
+  const block = incoming.slice(is, ie + END.length);
+  return current.slice(0, cs) + block + current.slice(ce + END.length);
+}
+
+/**
+ * Reconcile the game repo's agent surface against the installed engine artifact.
+ * Never throws: a malformed or absent surface must not block `looop dev`.
+ */
+export function reconcileAgentSurface(projectDir, engineDir, { log = console.log } = {}) {
+  const result = {
+    placed: [], removed: [], shadowed: [], backups: [],
+    adopted: false, skipped: false, engineVersion: null, backupDir: null,
+  };
+  const surface = join(engineDir, SURFACE_DIR);
+
+  let manifest;
+  try {
+    if (!existsSync(join(surface, 'manifest.json'))) {
+      result.skipped = true; // engine older than Slice 2 — it carries no surface
+      return result;
+    }
+    manifest = JSON.parse(readFileSync(join(surface, 'manifest.json'), 'utf8'));
+  } catch (err) {
+    log(`⚠️  Could not read the engine's agent surface (${err.message}) — skills left as they are.`);
+    result.skipped = true;
+    return result;
+  }
+
+  try {
+    const name = projectName(projectDir);
+    const render = (buf) => Buffer.from(buf.toString('utf8').replaceAll('{{name}}', name), 'utf8');
+
+    const prior = readLocal(projectDir);
+    // Adoption: a repo scaffolded before this mechanism existed has our files on
+    // disk but no record of them. We take ownership so it can ever be updated —
+    // and back up anything whose bytes diverge, so an edit we can't distinguish
+    // from ours is preserved rather than destroyed.
+    const adopt = prior === null;
+    result.adopted = adopt;
+    const placed = adopt ? {} : { ...prior.placed };
+
+    const backupRoot = join(projectDir, '.looop', `backup-${manifest.engineVersion}`);
+    const backups = [];
+    const backup = (rel) => {
+      const from = join(projectDir, rel);
+      if (!existsSync(from)) return;
+      const to = join(backupRoot, rel);
+      mkdirSync(dirname(to), { recursive: true });
+      cpSync(from, to, { recursive: true });
+      backups.push(rel);
+    };
+
+    // ── retired entries: remove what upstream dropped. This is the half that
+    //    makes a RENAME possible on a repo that already exists — without it a
+    //    replaced skill would linger next to its replacement forever. ─────────
+    for (const rel of manifest.retired ?? []) {
+      const dest = target(rel);
+      if (!dest) continue;
+      const abs = join(projectDir, dest);
+      if (!existsSync(abs)) continue;
+
+      const owned = Object.keys(placed).some((p) => p === dest || p.startsWith(`${dest}/`));
+      if (!owned && !adopt) {
+        result.shadowed.push(dest);
+        continue;
+      }
+      if (adopt) backup(dest);
+      rmSync(abs, { recursive: true, force: true });
+      for (const p of Object.keys(placed)) {
+        if (p === dest || p.startsWith(`${dest}/`)) delete placed[p];
+      }
+      result.removed.push(dest);
+    }
+
+    // ── the live surface ────────────────────────────────────────────────────
+    for (const rel of Object.keys(manifest.files ?? {})) {
+      const dest = target(rel);
+      if (!dest) continue;
+      const src = join(surface, rel);
+      if (!existsSync(src)) continue;
+
+      const abs = join(projectDir, dest);
+      const desired = render(readFileSync(src));
+      const exists = existsSync(abs);
+      const current = exists ? readFileSync(abs) : null;
+      const recorded = placed[dest];
+
+      if (dest === 'AGENTS.md') {
+        // The markers ARE the contract: inside is ours, outside is theirs.
+        const next = exists
+          ? spliceManaged(current.toString('utf8'), desired.toString('utf8'))
+          : desired.toString('utf8');
+        if (next === null) {
+          result.shadowed.push(dest);
+          continue;
+        }
+        if (exists && current.toString('utf8') === next) continue;
+        writeFileSync(abs, next);
+        placed[dest] = sha(Buffer.from(next, 'utf8'));
+        result.placed.push(dest);
+        continue;
+      }
+
+      if (exists) {
+        const now = sha(current);
+        if (now === recorded) {
+          if (now === sha(desired)) continue; // already current
+        } else if (recorded === undefined && adopt) {
+          if (now !== sha(desired)) backup(dest);
+        } else {
+          // Either they edited ours, or it was never ours. Both are theirs.
+          result.shadowed.push(dest);
+          placed[dest] = recorded ?? now;
+          continue;
+        }
+      }
+
+      mkdirSync(dirname(abs), { recursive: true });
+      writeFileSync(abs, desired);
+      placed[dest] = sha(desired);
+      result.placed.push(dest);
+    }
+
+    // ── orphans: anything WE placed that the artifact no longer ships ────────
+    // Deleting a skill upstream is enough to delete it here — no declaration,
+    // nothing to remember. The manifest already knows what we put on disk, so a
+    // file of ours that vanished from the artifact has been retired, full stop.
+    // (`retired` above still earns its keep: on ADOPTION there is no manifest,
+    // so an orphan is indistinguishable from a skill the creator wrote.)
+    const shipped = new Set(
+      Object.keys(manifest.files ?? {})
+        .map(target)
+        .filter(Boolean),
+    );
+    for (const dest of Object.keys(placed)) {
+      if (shipped.has(dest)) continue;
+      const abs = join(projectDir, dest);
+      if (existsSync(abs)) {
+        if (sha(readFileSync(abs)) !== placed[dest]) {
+          result.shadowed.push(dest); // they changed it — it's theirs now
+          continue;
+        }
+        rmSync(abs, { force: true });
+        pruneEmptyDirs(projectDir, dest);
+        result.removed.push(dest);
+      }
+      delete placed[dest];
+    }
+
+    writeLocal(projectDir, manifest.engineVersion, placed);
+    result.engineVersion = manifest.engineVersion;
+    result.backups = backups;
+    result.backupDir = backups.length
+      ? `${LOCAL_MANIFEST.replace('agent-surface.json', '')}backup-${manifest.engineVersion}/`
+      : null;
+  } catch (err) {
+    // A surface bug must never be the reason a creator can't run their game.
+    log(`⚠️  Could not sync the agent skills (${err.message}) — continuing; your game is unaffected.`);
+  }
+
+  return result;
+}
+
+// Used by `looop create`: the template seed IS the surface for a brand-new
+// repo, so record it as ours immediately. Without this the first `dev` would
+// treat a two-minute-old scaffold as an unknown pre-existing repo and adopt it.
+export function recordSeededSurface(projectDir, engineVersion) {
+  const placed = {};
+  const add = (rel) => {
+    const abs = join(projectDir, rel);
+    if (existsSync(abs)) placed[rel] = sha(readFileSync(abs));
+  };
+  const walk = (rel) => {
+    const abs = join(projectDir, rel);
+    if (!existsSync(abs)) return;
+    for (const entry of readdirSync(abs)) {
+      const child = join(rel, entry);
+      if (statSync(join(projectDir, child)).isDirectory()) walk(child);
+      else add(child);
+    }
+  };
+  walk(join('.claude', 'skills'));
+  add('AGENTS.md');
+  writeLocal(projectDir, engineVersion ?? null, placed);
+}

package/lib/create.mjs

@@ -19,6 +19,7 @@ import { join, relative, dirname } from 'node:path';
 import { getApiBase } from './config.mjs';
 import { DEFAULT_API_BASE } from './llm-shim.mjs';
 import { runNpm } from './npm.mjs';
+import { recordSeededSurface } from './agent-surface.mjs';
 
 export const TEMPLATE_DIR = join(import.meta.dirname, '..', 'template');
 
@@ -127,6 +128,12 @@ export async function create({
     ) + '\n',
   );
 
+  // The template we just copied IS this repo's agent surface, so record it as
+  // ours now (Slice 2 / Q2). Without this, the first `looop dev` would meet a
+  // two-minute-old scaffold with no ownership record, treat it as a legacy
+  // pre-Slice-2 repo, and noisily "adopt" it. From here the artifact drives it.
+  recordSeededSurface(dir, enginePin);
+
   if (install) {
     log(`Installing the CLI (npm install in ${name}/)…`);
     runNpm(['install', '--no-audit', '--no-fund'], { cwd: dir, stdio: 'pipe' });

package/lib/update.mjs

@@ -1,15 +1,53 @@
-// `looop update` — move this game to the latest engine release.
-// Asks the platform registry
-// for the latest downloadable release, rewrites the `looop.engine` pin, and
-// lets ensureEngine do what it already does on every dev/publish: download
-// (cached), install, re-pin. Slice 2 extends this with the skills/agent-
-// surface reconciliation once those ride the engine artifact.
-import { findProject } from './project.mjs';
+// `looop update` — move this game to the latest Looop: the engine bundle AND
+// the agent surface (skills + the Layer-0 managed block) that rides it.
+//
+// This is the ONLY command that writes to `.claude/skills/` or `AGENTS.md`
+// (creator-harness Slice 2 / Q2, scoped to update-only, 2026-07-11).
+// `dev` and `publish` never touch them: an update is something a creator asks
+// for, not something that happens to them while they were doing something else.
+//
+// Because it writes into files the creator has in git, it OWES them a full
+// account of what it changed — every path, and whose it was. The `/update-looop`
+// skill wraps this to walk them through the diff and offer the commit.
+import { findProject, resolveEngine } from './project.mjs';
 import { ensureEngine, readEnginePin, writeEnginePin } from './engine.mjs';
+import { reconcileAgentSurface } from './agent-surface.mjs';
 import { getToken, getApiBase } from './config.mjs';
 import { login } from './login.mjs';
 import { DEFAULT_API_BASE } from './llm-shim.mjs';
 
+// The report is the point. A creator reading this must be able to answer, with
+// no further digging: what changed, was any of it mine, and what do I do now.
+function report(log, engineVersion, surface) {
+  const { placed = [], removed = [], shadowed = [], backups = [], backupDir } = surface;
+  if (!placed.length && !removed.length && !shadowed.length) {
+    log('   Your skills and instructions were already current.');
+    return;
+  }
+
+  log('');
+  log(`Looop also updated this game's skills and instructions to match engine ${engineVersion}:`);
+  for (const f of placed) log(`   updated     ${f}`);
+  for (const f of removed) log(`   removed     ${f}   (retired by Looop)`);
+  for (const f of shadowed) log(`   KEPT YOURS  ${f}   (you changed it — we left it alone)`);
+
+  if (backups.length) {
+    // On adoption we cannot tell an untouched old platform file from one the
+    // creator edited — there is no ownership record to compare against, which
+    // is precisely why we're adopting. Most of these are just the previous
+    // version's files. Claiming "you edited these" would be a lie that alarms;
+    // saying nothing would risk a silent overwrite. State only what is true.
+    log('');
+    log(`   This game predates Looop's skill updates, so those files had no`);
+    log(`   ownership record. Their previous contents are saved in ${backupDir}`);
+    log(`   — if you had edited any of them, your version is in there.`);
+  }
+
+  log('');
+  log("   These are Looop's files inside your repo, so they show up in git as");
+  log("   changes you didn't make. Review them and save them with your next commit.");
+}
+
 export async function update({
   cwd = process.cwd(),
   apiBase = getApiBase(DEFAULT_API_BASE),
@@ -17,6 +55,7 @@ export async function update({
   fetchImpl = fetch,
   loginFn = login,
   ensure = ensureEngine,
+  reconcile = reconcileAgentSurface,
 } = {}) {
   const project = findProject(cwd);
   const from = readEnginePin(project.dir);
@@ -36,16 +75,36 @@ export async function update({
   const { latest } = await res.json();
   if (!latest) throw new Error('the platform has no downloadable engine releases yet.');
 
+  let engineDir = null;
+  let updated = false;
+
   if (from === latest) {
     log(`✅ Engine ${latest} — already up to date.`);
-    return { from, to: latest, updated: false };
+    // Reconcile anyway. A repo can sit on the latest engine and STILL have an
+    // out-of-date surface: one scaffolded before this mechanism existed has
+    // never had its skills adopted, and would otherwise wait forever for a
+    // release it already has.
+    try {
+      engineDir = resolveEngine(project.dir).dir;
+    } catch {
+      engineDir = null; // engine not installed yet — the next `dev` fetches it
+    }
+  } else {
+    // Rewrite the pin first; ensureEngine honors it (download → install → pin).
+    writeEnginePin(project.dir, latest);
+    const engine = await ensure(project.dir, { apiBase, log, fetchImpl });
+    engineDir = engine.dir ?? null;
+    updated = true;
+    log('');
+    log(`✅ Engine updated: ${from ?? '(none)'} → ${engine.version}`);
   }
 
-  // Rewrite the pin first; ensureEngine honors it (download → install → pin).
-  writeEnginePin(project.dir, latest);
-  const engine = await ensure(project.dir, { apiBase, log, fetchImpl });
-  log('');
-  log(`✅ Engine updated: ${from ?? '(none)'} → ${engine.version}`);
-  log('   Republish (`npx looop publish`) when you want the live game on it.');
-  return { from, to: engine.version, updated: true };
+  const surface = engineDir ? reconcile(project.dir, engineDir, { log }) : { skipped: true };
+  if (!surface.skipped) report(log, surface.engineVersion ?? latest, surface);
+
+  if (updated) {
+    log('');
+    log('   Republish (`npx looop publish`) when you want the live game on it.');
+  }
+  return { from, to: latest, updated, surface };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@looop-games/cli",
-  "version": "0.1.5",
+  "version": "0.1.7",
   "description": "Looop game development CLI — dev server, login, and publishing for standalone Looop games.",
   "type": "module",
   "license": "Apache-2.0",

package/template/.claude/skills/build/SKILL.md

@@ -112,6 +112,32 @@ they'd care about (feel, fairness, what can break) goes to them; one with no
 creator-visible consequence does not. Never hide a real fork to keep things
 simple — there is always a non-confusing way to ask it.
 
+**The shape decisions are ALWAYS the creator's** — never a default you carry in
+on their behalf, and never something you mention in passing as already settled:
+
+- **Camera and perspective** — top-down, side-on, isometric, first-person, 3D.
+  There is no house camera; see `/engine`'s render paths.
+- **Art direction and look** — the Looop iso kit is *available*, not mandatory.
+- **The core verb** — what the player actually does, moment to moment.
+- **How conflict works** — combat, avoidance, puzzles, none of the above.
+- **Single-player vs. co-op vs. competitive** feel (the *plumbing* is always
+  multiplayer-first; what the game is *about* is theirs).
+
+**NEVER invent a platform constraint.** Do not tell the creator "the engine
+only does X", "Looop doesn't support Y", or "that would take months" unless you
+have just checked and can point at what says so. A Looop game is a web page;
+the library is a bag of conveniences, not a fence (`/engine` — "The library is
+NOT the limit"). This failure is worse than a silent default: a creator can
+argue with "that's a lot of work", but they cannot argue with "the platform
+can't", so a fabricated limit kills their idea and looks like physics while
+doing it. If a thing is genuinely unbuilt, that is a **cost to price honestly**
+and hand them — never a "no" you issue on Looop's behalf.
+
+Watch for this specifically when scope pressure and a gap in the library point
+the same way: **"default to the smallest build" is never a licence to narrow
+the creator's vision** — that's the scope-narrowing this skill forbids two
+paragraphs down, wearing a technical disguise.
+
 **Default to the smallest build that meets the creator's ask — never inflate
 scope.** Every "we could also…" and every richer-than-asked option is scope
 YOU are injecting; the creator can't push back on over-building they didn't
@@ -192,7 +218,7 @@ Outcomes:
   back to the last save (`git reset --hard` — nothing was saved mid-milestone,
   so that's the last accepted state).
 - **The playtest caught a defect you missed** → that's a hole in the
-  verification, not just a bug. Fix it, then run `/update-handbook` so this
+  verification, not just a bug. Fix it, then run `/handbook` so this
   class of defect gets an automated check and never reaches a playtest again.
 
 ## 5. Offer publish — never publish on your own

package/template/.claude/skills/engine/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: engine
-description: Discover what the Looop engine already provides before building something from scratch — components (rooms, physics, audio, joysticks, leaderboards, LLM NPCs…), craft docs, and how to customize engine behaviour. Use when the creator asks "can it do X?", when you're about to write a system a game engine would normally provide, or when tuning game feel.
+description: Discover what the Looop engine already provides before building something from scratch — its component library, craft docs, and how to customize engine behaviour. Read the index rather than assuming what exists. Use when the creator asks "can it do X?", when you're about to write a system a game engine would normally provide, or when tuning game feel.
 ---
 
 # /engine — what Looop already gives you
@@ -11,6 +11,42 @@ system from scratch — movement, audio, UI, chat, NPCs, scoring — check wheth
 the engine already has it. Reinventing a library is the most common way a game
 gets worse.
 
+**But the library is a floor, not a ceiling — read the next section before you
+ever tell the creator something isn't possible.**
+
+## The library is NOT the limit of what the game can be
+
+A Looop game is **a web page**. Anything the browser can do, the game can do.
+The engine saves you work; it does not bound the game. The catalog is what
+Looop has *already built for you* — never mistake it for the list of things a
+Looop game is allowed to be.
+
+So there are only ever two answers to "can Looop do X?":
+
+1. **The library has it** → use it (don't reinvent it).
+2. **The library doesn't** → **then you build it, in the game folder.** That is
+   the normal, expected path — it is how the library got its entries in the
+   first place. Price it honestly and let the creator decide.
+
+**Never say "the engine doesn't support that" as if it settled the question.**
+It is the most damaging sentence you can say to a creator: it retires their
+idea without their consent, and it is almost always false. If you catch
+yourself about to say it — stop, come back here, and check. What you *may* say
+is an honest **cost**: "nothing in the kit does this, so we'd build it; here's
+roughly what that means." Price it from what actually exists, never from a
+worst case you imagined.
+
+## Render paths (the camera is the creator's decision, not yours)
+
+There is no house camera. Pick with the creator, framed by consequences:
+
+| path | what it is |
+| --- | --- |
+| **plain 2D canvas** | `getContext('2d')` — what the scaffold ships with. Top-down, side-on, whatever you draw. Lightest. |
+| **iso 2D** (`shared/ui/iso` + `iso-style-looop`) | Isometric 3/4 canvas drawing with the Looop world kit. The best-supported look. Depth is a painter-algorithm sort, so large occluders can glitch. |
+| **iso-3d** (`shared/ui/iso-3d`) | Real WebGL/three.js geometry with per-pixel depth-buffer occlusion. Same iso look, no depth-sort bugs. |
+| **anything else** | First-person, over-the-shoulder, free 3D camera, 2.5D — all buildable on three.js in the game folder. Less kit support, not less possible. |
+
 ## Discover
 
 1. **Start at the index:**
@@ -57,3 +93,8 @@ when the behaviour truly must change inside the engine module.
   game would want** → that's platform feedback: `/feedback`.
 - The need is **specific to this game** → build it game-local (or override),
   and note in `handbook/design.md` if it's a pillar.
+- The engine has **nothing at all** for something many games would want (a
+  whole render path, a genre's core system) → do **both**: build it game-local
+  so the creator is never blocked waiting on Looop, *and* `/feedback` it so
+  Looop can make it first-class. Never let a gap in the library become a "no"
+  to the creator.

package/template/.claude/skills/handbook/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: handbook
+description: The entry point to this game's handbook — its durable truth. Use when you need to know what this game already believes (before building, before proposing anything), and when something durable emerges that belongs in it — a design pillar, a blessed feel value, or a playtest catch that needs converting into an automated check. Also use when durable truth appears that has no chapter yet (the game's vision, its world, its cast, its economy) and one should be started.
+---
+
+# /handbook — what this game knows about itself
+
+`handbook/` is this game's **durable truth**: the things a future session must
+not violate, and must not have to re-derive. It is the game's own layer on top
+of the engine's read-only craft docs — where they touch the same topic, the
+handbook is *this game's* answer.
+
+Three places knowledge lives here; keep them straight:
+
+| | Holds | Lifespan |
+|---|---|---|
+| **`handbook/`** | what this game IS and has decided | durable — outlives every plan |
+| **`notes/`** | what we're building or might build (`plans/`, `todos/`) | transient — closed when the work is |
+| the engine's `shared/practices/` | how Looop games are built in general | read-only, ships with the engine |
+
+The test for whether something belongs here: **would a future session need to
+*not violate* this?** → handbook. *Is it something we're doing, or might do?* →
+`notes/`.
+
+## The chapters
+
+```
+handbook/
+  design.md   the pillars — what this game IS, checked against new ideas
+  feel.md     locked feel values the creator has blessed
+  qa.md       checks this game has earned (mostly from playtests that caught something)
+```
+
+**The set is open, and these three are only where it starts.** They ship with
+every game because every game accumulates them. They are not the limit, and they
+are not a template to fill in — what else a handbook holds depends entirely on
+what this game turns out to need. See *Starting a new chapter*.
+
+## Reading it — do this before you build
+
+**`ls handbook/` and read what's relevant before writing game code or proposing
+a direction.** Every chapter opens with a line saying what it's for, so the
+folder listing plus the first two lines of each file is a cheap orientation.
+Reading is free; contradicting the handbook and being caught later is not.
+
+If what you're about to propose **contradicts something the handbook already
+says**, that is not a detail to smooth over — stop and say so. Either the idea is
+wrong, or what's written is out of date and the creator needs to say so out loud.
+Never quietly build against it.
+
+An empty chapter is honest — an early game hasn't decided much yet, and a
+speculative pillar nobody has lived is worse than none.
+
+## Growing it
+
+**Every handbook write needs the creator's approval first.** The handbook is
+*their* game's truth — propose the exact entry ("I'd like to record: …") and
+write it only after they say yes. Never slip an entry in as a side effect of
+other work. (Smoke/test FILES don't need this gate — they're regression tests,
+not blessed truth; only `handbook/` writes do.)
+
+### A design principle emerged → `handbook/design.md`
+
+When a decision reveals what this game IS ("never text tutorials — the world
+teaches", "death must always be the player's fault"), write the pillar down.
+Future builds check new ideas against these.
+
+### A playtest caught a defect → an automated check
+
+The premise (from the engine's `shared/practices/qa.md`): **a human catching a
+defect means an automated check was missing.** Convert the *class* of defect,
+not the instance:
+
+1. Name the miss precisely — not "the door was broken" but "doors can lose
+   their collision when the room resets, and nothing checks collision after a
+   reset."
+2. Prefer an **executable check**: write a `<aspect>.smoke.mjs` (or
+   `*.test.mjs`) that reproduces the defect — confirm it fails RED on the
+   broken state, then goes green on the fix. `npx looop test` discovers it
+   forever after; a guard you never saw fail is a guard you can't trust.
+3. **If the check needs to SEE the game's internals** (collision boxes, depth
+   order, hit areas) and the game has no debug overlay yet, **build one as part
+   of the conversion** — a keyboard-toggled draw of the real boxes/order. It's
+   a small one-time cost, and every later screenshot-verify reuses it (master
+   list row R2).
+4. Only if it truly can't be executed (needs human perception), add it as a
+   procedural step in **`handbook/qa.md`** — `/qa` runs those by hand each time.
+
+## Starting a new chapter
+
+The four standing chapters won't fit everything. When durable truth appears
+that belongs in none of them, **start a chapter** — that is the handbook
+working as intended, not a special case.
+
+A subject earns a chapter when it is: **durable** (it outlives the current
+plan), **referred back to** (future sessions need it to stay consistent), and
+**not a fit** for an existing chapter. It can be anything this game actually
+needs: `vision.md` (what the game is *for*, once the creator has said it out
+loud), `world.md` (a setting an agent must not contradict), `characters.md`,
+`economy.md` (numbers that have to balance), `controls.md`. Don't shop from that
+list — reach for whatever this game keeps needing to remember.
+
+To start one:
+
+1. **Propose it** — the name, and the exact first entry. Same approval gate as
+   any handbook write; creating a chapter is a bigger act than adding a line,
+   not a smaller one.
+2. Create `handbook/<subject>.md` with the standard shape:
+
+   ```markdown
+   # <Subject> — <what this chapter is for, in half a line>
+
+   <One or two sentences: what belongs here, what doesn't.>
+
+   ## YYYY-MM-DD — <the entry>
+   <The truth itself. Short. Actionable cold, by someone who wasn't there.>
+   ```
+
+3. Don't pre-create chapters "in case", and don't propose one because the game
+   "ought to" have it. An empty speculative chapter is a trap — it invites
+   invented content, and a creator filling in a template is not the same as a
+   creator telling you something true. A chapter starts the day it has something
+   true to hold.
+
+## The upstream half
+
+Before writing, ask: **is this lesson specific to this game, or would every
+Looop game want it?** A generic hole (an engine component that breaks a
+universal expectation, a check every game should run) belongs in the engine's
+master list, not just this repo — offer `/feedback` so it lands upstream for
+everyone. Do both when in doubt: the handbook entry protects this game now; the
+feedback fixes it everywhere later.
+
+## Rules
+
+- **One lesson per invocation, converted fully** — an entry someone can act on
+  cold, not a vague reminder.
+- **Date entries.** When a later decision supersedes one, update it **in place**
+  rather than stacking contradictions — a handbook that argues with itself is
+  worse than no handbook, because a future session will pick the wrong side.
+- **Short.** Every line in here is read by every future session. It earns its
+  place or it goes.

package/template/.claude/skills/qa/SKILL.md

@@ -40,7 +40,7 @@ creator's list.
    URL to open, never a command to run). If everything was automatable, say
    so plainly; "couldn't test it" must never read as "tested and fine".
 5. **Close the ratchet.** If the creator's pass catches something your run
-   missed, that's a hole in the checks — run `/update-handbook` to convert
+   missed, that's a hole in the checks — run `/handbook` to convert
    that defect class into an automated check.
 
 ## Notes

package/template/.claude/skills/update-looop/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: update-looop
+description: Update Looop itself — the engine, and the skills and instructions this repo runs on. Use when the creator asks for the latest Looop ("is there an update?", "update looop", "get the newest version"), when a Looop feature they've heard about is missing, or when something looks like a Looop bug that may already be fixed. Not for updating their GAME — that's just building.
+---
+
+# /update-looop — get the latest Looop, and explain what changed
+
+`npx looop update` moves this game to the newest Looop release. It is the **only**
+command that writes to Looop's files inside this repo — `dev` and `publish` never
+do. That is deliberate: an update is something the creator *asks* for.
+
+But it does write into **their** repo. After it runs, `git status` shows changes
+they did not make. **Your job is to make sure that is never a surprise.**
+
+## Before
+
+Tell them what an update touches, in one or two sentences:
+
+- **The engine** — the game code they import from (`/shared/...`). Their game
+  keeps running on the old engine until they publish again, so an update is safe
+  to take at any time.
+- **The skills and instructions** — the files in `.claude/skills/` and the Looop
+  section of `AGENTS.md`. These are Looop's, living in their repo.
+- **Never their game.** Not `index.html`, not `game.js`, not `handbook/`, not
+  `notes/`. And never a skill they wrote, or an edit they made to one of ours —
+  where they've changed something, their version wins and the update says so.
+
+If they have uncommitted work, say so first — the update's changes will land
+alongside it, and a mixed diff is harder to read. Offer to save theirs first.
+
+## Run it
+
+```bash
+npx looop update
+```
+
+It prints exactly what it did: every file updated, every file removed, and every
+file it **kept because the creator had changed it**. Read that output — it is the
+source of truth for the next step, not your assumptions about what a release
+contains.
+
+## After — the part that matters
+
+**Report the change in their terms, not ours.** Don't paste the file list back at
+them; tell them what is now different about what you and they can do:
+
+> *"Looop updated to engine 0.1.8. The `/update-handbook` skill was replaced by a
+> broader `/handbook` — same job, plus it now keeps your game's vision and design
+> pillars. Your own `/my-thing` skill was left alone."*
+
+Then **offer the commit** — never run it unasked:
+
+> *"That changed 3 of Looop's files in your repo. Want me to save them?
+> (`git add -A && git commit -m "update Looop to engine 0.1.8"`)"*
+
+Two things to volunteer without being asked:
+
+- **If they'd edited a Looop file**, the update kept *their* version and did not
+  apply ours. Say which file, and that they may want to re-apply their change on
+  top of the new one — otherwise they'll silently miss the update to that file
+  forever.
+- **If the update mentions a backup folder** (`.looop/backup-<version>/`), that
+  is the pre-update copy of files whose history we couldn't be sure of. Tell them
+  it exists. They can delete it once they're happy.
+
+## Rules
+
+- **Never run `looop update` as a side effect of something else.** It is its own
+  act, with its own consent. If a bug looks like it might already be fixed
+  upstream, *propose* the update — don't just do it mid-build.
+- **Never commit on their behalf** without asking, even when the only changes are
+  Looop's own files. It is their repo and their history.
+- The live game at `play.looop.games` does **not** change until they run
+  `npx looop publish`. Say so — creators reasonably assume an update is live.

package/template/AGENTS.md

@@ -19,7 +19,7 @@ applies. This table routes only what has no skill:
 | The creator wants… | Do this |
 |---|---|
 | To "save my work" | `git add -A && git commit` (and push, if the repo has a remote). Saving is local; it is **not** publishing. |
-| To update Looop / the engine | `npx looop update` — moves the game to the latest engine release and re-pins `looop.engine` in `package.json`. The live game changes only on the next publish. |
+| To update Looop / the engine | `/update-looop`. It is the ONLY thing that writes Looop's files into this repo (`.claude/skills/`, the managed block of this file) — `dev` and `publish` never do, so an update is never a surprise in their git. The live game changes only on the next publish. |
 | Better game feel (tuning speeds, jumps, timings) | The engine's **tweaks** library (`node_modules/@looop-games/engine/shared/ui/tweaks/`) + `shared/practices/feel.md`. |
 | To change how an engine file behaves | Copy it to `overrides/shared/<same path>` and edit the copy — dev and publish serve your override instead of the official module. Imports stay `/shared/...`; never rewrite them. An override is a fork: that file stops receiving engine updates until you re-port it. |
 
@@ -48,11 +48,18 @@ applies. This table routes only what has no skill:
    scores, world objects) rides the room's authority — `room.update(...)`,
    `room.send('input', ...)` — never local mutation only one client sees.
    Verify multiplayer behaviour with TWO browser contexts, not one.
-2. **The engine is read-only.** `/shared/...` imports come from the installed
-   engine at `node_modules/@looop-games/engine` (not an npm dependency —
-   `looop dev` downloads the version pinned in `package.json`'s `looop.engine`
-   and reinstalls it if an `npm install` prunes it). Never edit files in
-   `node_modules` — use `overrides/shared/` (see the table above).
+2. **The engine is read-only — and it is not the ceiling.** `/shared/...`
+   imports come from the installed engine at `node_modules/@looop-games/engine`
+   (not an npm dependency — `looop dev` downloads the version pinned in
+   `package.json`'s `looop.engine` and reinstalls it if an `npm install` prunes
+   it). Never edit files in `node_modules` — use `overrides/shared/` (see the
+   table above). But read-only means *don't edit it*, **not** *don't exceed
+   it*: a Looop game is a web page, so **anything the browser can do, this game
+   can do.** The library is a bag of conveniences you draw from, not a fence
+   around what the game may be — what it doesn't have, you build, here in the
+   game folder. **Never tell the creator that Looop "can't" do something**
+   (see `/engine` — it is almost always false, and it retires their idea
+   without their consent).
 3. **Never hand-roll a server.** Only `looop dev` (or `looop test`) serves
    this game: they alias `/shared/...` and inject the platform layer. A plain
    static server 404s every engine import and the game silently never boots.
@@ -75,7 +82,7 @@ applies. This table routes only what has no skill:
 
 - **`handbook/`** — durable truth about THIS game: `qa.md` (its checks),
   `feel.md` (locked feel values), `design.md` (its pillars). Consult it before
-  working; grow it with `/update-handbook`.
+  working; grow it with `/handbook`.
 - **`notes/`** — work tracking: `notes/plans/` (what's being built — `/build`
   runs from these), `notes/todos/` (captured bugs/ideas), and
   `notes/feedback/` (reports for the Looop team, written by `/feedback`).

package/template/handbook/design.md

@@ -1,7 +1,8 @@
 # Design — the pillars
 
-What this game IS: the principles new ideas get checked against. Written as
-they emerge from real decisions (via `/update-handbook`), not invented up
+The rules that follow from the vision: the principles new ideas get checked
+against. Written as
+they emerge from real decisions (via `/handbook`), not invented up
 front — an empty file is honest; a speculative pillar is a trap.
 
 _No pillars yet._

package/template/handbook/feel.md

@@ -3,6 +3,6 @@
 Feel calls the creator has blessed: the value, where it lives, and why it's
 right — so no future session "improves" them away. General feel craft lives in
 the engine's `shared/practices/feel.md`; this file is only what THIS game has
-locked. `/update-handbook` adds entries.
+locked. `/handbook` adds entries.
 
 _Nothing locked yet._

package/template/handbook/qa.md

@@ -2,7 +2,7 @@
 
 Checks THIS game has earned, on top of the engine's master list
 (`node_modules/@looop-games/engine/shared/practices/qa.md`) and the executable
-tests `npx looop test` discovers. `/qa` runs all three sources; `/update-handbook`
+tests `npx looop test` discovers. `/qa` runs all three sources; `/handbook`
 adds entries here when a playtest catches something no automated check saw —
 but prefer writing a `*.smoke.mjs` when the check can be executed.
 

package/template/.claude/skills/update-handbook/SKILL.md

@@ -1,69 +0,0 @@
----
-name: update-handbook
-description: Record something durable this game just taught us — convert a playtest catch into an automated check, lock in a blessed feel value, or write down a design pillar. Use right after a creator playtest catches a defect the automated checks missed, when a feel value gets approved ("that jump is perfect — keep it"), or when a design principle emerges.
----
-
-# /update-handbook — keep what the game taught us
-
-`handbook/` is this game's durable truth — the layer that AUGMENTS the
-engine's read-only practices with what THIS game has learned. This skill is
-how it grows.
-
-**Every handbook write needs the creator's approval first.** The handbook is
-*their* game's truth — propose the exact entry ("I'd like to record: …"),
-and write it only after they say yes. Never slip an entry in as a side effect
-of other work. (Smoke/test FILES don't need this gate — they're regression
-tests, not blessed truth; only `handbook/` writes do.)
-
-Three kinds of lesson, three destinations:
-
-## 1. A playtest caught a defect → an automated check
-
-The premise (from the engine's `shared/practices/qa.md`): **a human catching a
-defect means an automated check was missing.** Convert the *class* of defect,
-not the instance:
-
-1. Name the miss precisely — not "the door was broken" but "doors can lose
-   their collision when the room resets, and nothing checks collision after a
-   reset."
-2. Prefer an **executable check**: write a `<aspect>.smoke.mjs` (or
-   `*.test.mjs`) that reproduces the defect — confirm it fails RED on the
-   broken state, then goes green on the fix. `npx looop test` discovers it
-   forever after; a guard you never saw fail is a guard you can't trust.
-3. **If the check needs to SEE the game's internals** (collision boxes, depth
-   order, hit areas) and the game has no debug overlay yet, **build one as
-   part of the conversion** — a keyboard-toggled draw of the real boxes/order.
-   It's a small one-time cost, and every later screenshot-verify reuses it
-   (master list row R2).
-4. Only if it truly can't be executed (needs human perception), add it as a
-   procedural step in **`handbook/qa.md`** — `/qa` runs those by hand each
-   time.
-
-## 2. A feel value got blessed → `handbook/feel.md`
-
-When the creator locks a feel call ("that speed is exactly right"), record the
-value, where it lives, and WHY it's right — so no future session "improves" it
-away. If it's worth defending, pin it with a smoke too.
-
-## 3. A design principle emerged → `handbook/design.md`
-
-When a decision reveals what this game IS ("never text tutorials — the world
-teaches", "death must always be the player's fault"), write the pillar down.
-Future builds check new ideas against these.
-
-## The upstream half
-
-Before writing, ask: **is this lesson specific to this game, or would every
-Looop game want it?** A generic hole (an engine component that breaks a
-universal expectation, a check every game should run) belongs in the engine's
-master list, not just this repo — offer `/feedback` so it lands upstream for
-everyone. Do both when in doubt: the handbook entry protects this game now;
-the feedback fixes it everywhere later.
-
-## Rules
-
-- One lesson per invocation, converted fully — an entry someone can act on
-  cold, not a vague reminder.
-- Handbook entries are durable truth: date them, keep them short, and when a
-  later decision supersedes one, update it in place rather than stacking
-  contradictions.