@looop-games/cli 0.1.8 → 0.1.9

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

@@ -1,100 +0,0 @@
----
-name: engine
-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
-
-The engine is installed at `node_modules/@looop-games/engine` (downloaded by
-`looop dev`, pinned in `package.json`'s `looop.engine`). Before writing any
-system from scratch — movement, audio, UI, chat, NPCs, scoring — check whether
-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:**
-   `node_modules/@looop-games/engine/shared/ui/INDEX.md` — the component
-   library at a glance, one line per component.
-2. **Read the component's README before using it** —
-   `node_modules/@looop-games/engine/shared/ui/<component>/README.md`. Each
-   documents its import, API, and the practices around it.
-3. **Import by absolute path**, e.g.
-   `import { createRoom } from '/shared/ui/room/client.js'`. In dev and in
-   production those resolve to the installed engine version — never to files
-   you can edit.
-
-## The craft docs
-
-`node_modules/@looop-games/engine/shared/practices/` is the engine's
-accumulated craft knowledge and applies to every game:
-
-- `feel.md` — what makes a game feel good; read before tuning anything.
-- `architecture.md` — how Looop games are structured.
-- `multiplayer.md` — authority, prediction, and the rules of shared state.
-- `qa.md` — the master verification list (`/qa` runs it).
-
-**Game feel specifically:** the `tweaks` library
-(`shared/ui/tweaks/` — see its README) is the engine's tuning surface; use it
-with `feel.md` rather than scattering magic numbers.
-
-## Customize — overrides, never edits
-
-The engine is read-only; never edit `node_modules`. To change how an engine
-file behaves for THIS game:
-
-1. Copy it to `overrides/shared/<same path as under shared/>`.
-2. Edit the copy. Dev and publish both serve your override instead of the
-   official module — game imports stay `/shared/...`, never rewritten.
-
-An override is a fork: that file stops receiving engine updates until you
-re-port it. Prefer game-local code when it can live in the game; override only
-when the behaviour truly must change inside the engine module.
-
-## When the engine falls short
-
-- The engine has the component but it's **broken or missing something every
-  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/feedback/SKILL.md

@@ -1,125 +0,0 @@
----
-name: feedback
-description: File feedback to the Looop team when something in Looop ITSELF is broken or missing — the engine, a shared component, the looop CLI, login, publishing, the platform. Use the moment you or the creator think "this looks like a Looop bug, not our game" — AND, just as importantly, whenever you discover your own game breaking a Looop rule, because Looop's own instructions may be what put it there. Offer to file it right away; don't wait to be asked.
----
-
-# /feedback — tell Looop when Looop is the problem
-
-You are often the only witness when the platform misbehaves. The reflex this
-skill exists for: the moment something smells like a **Looop** defect — an
-engine component behaving wrong, a `looop` command failing strangely, docs
-that lied, a missing capability every game would want — **offer to file it**:
-"that looks like a Looop bug, want me to send it to the Looop team?"
-
-This game's own bugs are NOT feedback — they're `/todo`s or just fixes.
-
-## The defect you will not notice
-
-There is one class of Looop bug the reflex above is blind to, and it is the most
-valuable class there is: **a defect Looop's own guidance caused.**
-
-It looks like this. You discover your game violating a Looop rule — it's routing
-state the wrong way, using an API it shouldn't. The symptom is in *your* code, so
-the conclusion writes itself: *"our bug, not the engine's."* You fix your game and
-move on, and Looop never hears about it.
-
-That inference is locally correct and globally wrong. **Looop's instructions are
-not a fixed point — they are a suspect.** They contradict each other sometimes.
-The mandatory ones (this repo's `AGENTS.md`, injected into every session) can be
-wrong while an opt-in practices doc is right, and you will have followed the
-mandatory one without ever noticing there was a choice.
-
-So, the rule:
-
-> **When you find your game violating a Looop rule, work out what led you there
-> BEFORE you fix it.**
-
-Retrace it honestly. Did a Looop-authored source — `AGENTS.md`, a
-`shared/practices/` doc, a library README, a skill — point you this way? If yes,
-**that is a Looop defect and it gets filed**, even though your game is also wrong.
-Both are true at the same time; fix your game *and* file the report. If you'd have
-made the same mistake with no guidance at all, it's just your bug — fix it and
-move on.
-
-## What to file
-
-Write the report to `notes/feedback/<YYYY-MM-DD-HHMM>-<short-slug>.md`
-(creation datetime first, like everything under `notes/`). **You are the author,
-not the creator — so be maximal.** The Looop team gets nothing but this file;
-they can't ask you follow-ups, re-run your session, or see your screen. Every
-detail you leave out is a detail they'll have to guess. Include:
-
-```markdown
----
-created: YYYY-MM-DD
-engine: <the looop.engine pin from package.json>
-cli: <@looop-games/cli version from package.json devDependencies>
-attachments:
-  - game.js
-  - src/net.js
----
-# <One line: what's wrong>
-
-**What happened:** …
-**What was expected:** …
-
-## Environment
-OS, node version, and anything unusual about the setup (worktree lane,
-custom port, offline, …).
-
-## Reproduction
-The smallest steps/snippet that shows it. Exact commands **with their full
-output pasted verbatim** — never summarize an error message.
-
-## What led us here (if a Looop source did)
-The file and line that pointed you wrong, quoted, and the doc that contradicts
-it. This is the section that gets the guidance itself fixed.
-
-## Transcript
-The conversation that surfaced this, quoted verbatim — from the creator's
-request that first hit the problem through your diagnosis: what they asked,
-what you ran, what came back, what you ruled out. This is usually the most
-valuable section; a reader should be able to replay your session from it.
-
-## Workaround used (if any)
-e.g. an overrides/shared/ copy, so the team knows what to un-fork once fixed.
-```
-
-Trim game-specific noise, never evidence: cut what's irrelevant to the
-defect, keep everything that shows it. (The intake caps a report at 256 KiB —
-if the transcript pushes past that, cut it down to the relevant exchange.)
-
-## Attach the files you're talking about
-
-A report that cites `game.js:56` is only as good as the reader's ability to see
-line 56. **List the files your diagnosis rests on in the `attachments:`
-frontmatter** — they ship with the report, and the team reads them beside it.
-
-This applies to **any** report, whatever its reason: a bug, a missing capability,
-a rule that led you wrong, a module you had to fork. Whatever your evidence is,
-attach it.
-
-- **You pick the files** — you wrote the diagnosis, so you know what it rests on.
-- Paths are **relative to the game folder** and must stay inside it. Anything
-  pointing outside is refused outright.
-- **Text only** (source, logs, config) — up to 20 files, 256 KiB each, 1 MiB total.
-- Attach what the report *argues from*: the file with the bug, the module you
-  worked around, the config that reproduces it. Not the whole game.
-
-## Send it
-
-1. Run **`npx looop feedback`** — it delivers every unsent report under
-   `notes/feedback/` to the Looop team (login required; it's the same account
-   as publishing), attachments included, and stamps each delivered file with
-   `sent:` + `id:` in its frontmatter so it never ships twice.
-2. If the send fails (offline, not logged in, a bad attachment path), the file
-   stays unstamped — fix what it says and run `npx looop feedback` again; it
-   retries everything unsent.
-
-## Why bother
-
-An override that patches an engine bug is a fork that stops receiving updates;
-feedback is how the fix lands upstream so the fork can be deleted. A missing
-capability filed from a real game is exactly how the engine decides what to build
-next. And a rule that led you wrong will lead **every** creator wrong, in every
-game, until somebody says so.

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

@@ -1,142 +0,0 @@
----
-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

@@ -1,53 +0,0 @@
----
-name: qa
-description: Verify the current change — run every automated check that applies and hand the creator only the shortest possible list of things that genuinely need human eyes. Use when the creator asks "does it work?", before any playtest handback, or whenever work is about to be called done.
----
-
-# /qa — run the game's checks, hand back only what needs a human
-
-The QA framework lives in ONE place: the engine's master doc at
-`node_modules/@looop-games/engine/shared/practices/qa.md` — what counts as an
-**automated** step (you run it, you report it) vs a **manual** one (only the
-creator can judge it), the ratchet, and the master steps list. **Read it
-first, every time. This skill is the procedure; the steps live there.** 
-
-The governing rule (from that doc): **maximize automated, drive manual toward
-zero.** Anything you *can* run, you run and report — it never goes on the
-creator's list.
-
-## The three sources of checks (merge all three)
-
-1. **Executable checks — `npx looop test`.** Discovers and runs every
-   `*.test.mjs` and `*.smoke.mjs` in this folder against a real dev stack.
-   The files ARE the list; always the whole gate, not just new tests.
-2. **This game's earned checks — `handbook/qa.md`.** Procedural steps this
-   specific game accumulated (past playtest catches, fragile spots).
-3. **The engine master list** — the doc above. Generic steps every Looop game
-   is checked against.
-
-## Procedure
-
-1. **Scope the change** — which surfaces did it touch? That selects which
-   master-list rows and handbook steps apply.
-2. **Run every automated step that applies**, from all three sources. Where
-   the master doc calls for fresh reviewer or adjudicator sub-agents, spawn
-   them yourself with the briefs it describes.
-3. **Report results concretely** — how you verified, not "tested": suite
-   counts, which URL you drove, what the screenshot showed, findings resolved.
-4. **Emit the minimal human list.** Only feel/look/judgment items and things
-   you genuinely couldn't verify — each against a game that is **already
-   running** (start or reuse the dev stack yourself; the creator gets the
-   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 `/handbook` to convert
-   that defect class into an automated check.
-
-## Notes
-
-- `/qa` verifies; it never commits or publishes.
-- Smokes drive a real browser with Playwright — **already in this repo's
-  devDependencies** (`looop create` ships it and pre-fetches Chromium, and
-  `looop test` re-fetches the browser if the cache was pruned). Only a repo
-  scaffolded before playwright shipped needs the one-time
-  `npm i -D playwright && npx playwright install chromium`.

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

@@ -1,54 +0,0 @@
----
-name: todo
-description: Capture a bug, idea, or improvement for later without acting on it now. Use when the creator (or you, mid-build) spots something worth remembering — "we should fix that jump later", "idea — a boss level", "note that down" — and when they want to see what's captured or start work on one.
----
-
-# /todo — capture now, decide later
-
-A **todo** is the one lightweight capture type in this repo: bug, idea,
-improvement — all the same thing until someone decides to act. Capturing must
-be nearly free; never derail the current work to file one.
-
-## Capture
-
-Write one small file per todo at `notes/todos/<YYYY-MM-DD-HHMM>-<short-slug>.md`
-(creation datetime first, always — the whole `notes/` tree names files this way
-so they list in order):
-
-```markdown
----
-status: open   # open | done | promoted | abandoned
-created: YYYY-MM-DD
----
-# <One-line summary>
-
-What was seen / imagined, in a couple of sentences. Enough that a future
-session understands it cold. Reference files by path if relevant.
-```
-
-Then get back to what you were doing. If the creator says something mid-build
-that is clearly a "later" item, offer to capture it in one line — don't stop
-the milestone.
-
-## Browse
-
-"What's on the list?" → read `notes/todos/`, summarize the open ones in a few
-lines each. Group bugs vs ideas by content, not by folder — there is
-deliberately only one folder.
-
-## Promote
-
-When the creator decides to actually DO a todo, it becomes a **plan**: start
-`/build`, which creates the plan in `notes/plans/` through its discussion
-phase, seeded from the todo's content. Mark the todo `status: promoted` with a
-line pointing at the plan file. Small fixes don't need promotion — just do
-them and mark the todo `done`.
-
-## Rules
-
-- Never delete a todo — mark it `done` (with a line saying what happened),
-  `promoted`, or — when the creator decides NOT to do it — `abandoned` **with
-  a one-line why**. The why is the value: it saves re-deciding the same thing
-  next month. "Won't do" and "did it" must never collapse into one status.
-- A todo about **Looop itself** (the engine, the CLI, the platform — not this
-  game) is `/feedback`'s job, not a todo.

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

@@ -1,74 +0,0 @@
----
-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

@@ -1,93 +0,0 @@
-# {{name}} — a Looop game
-
-<!-- looop:managed:start -->
-<!-- Everything between the looop:managed markers belongs to the Looop
-     platform and is REWRITTEN when the engine updates. Add your own
-     instructions BELOW the end marker — updates never touch them. -->
-
-This folder is a standalone Looop game. You (the agent) build it for a person
-who is probably **not a developer** — the "creator". They describe the game in
-plain language and make the judgment calls; you own everything else: process,
-code, and verification. They should never need to learn git, npm, or servers.
-
-## Where things go
-
-The workflows live as **skills** in `.claude/skills/` (aliased at
-`.agents/skills/` — same files); each skill's `description` says when it
-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 | `/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. |
-
-## Commands (run from this folder)
-
-- `npx looop dev` — the full local stack: the game at
-  http://localhost:8000/games/{{name}}/index.html, multiplayer on :1999,
-  platform services (LLM etc.) on :8788. Leave it running; edits hot-reload.
-  **On a new machine the first `dev` signs the creator in: a browser window
-  opens, they log in and click Approve (~30 seconds, once per machine). Tell
-  them it's coming BEFORE you run it** — an unexplained browser popup mid-build
-  reads as something going wrong.
-- `npx looop test` — the per-change gate: runs every `*.test.mjs` (unit, under
-  node) and every `*.smoke.mjs` (against a real dev stack it boots itself on
-  free ports) in this folder.
-- `npx looop login` — connect this machine to the creator's Looop account
-  (once per machine; the first `looop dev` runs it automatically).
-- `npx looop publish` — ship to https://play.looop.games/g/{{name}}.
-  **The first publish permanently claims the name `{{name}}` for the creator's
-  account** — from then on only they can update it. `--slug <alt>` publishes an
-  A/B copy without touching the live game.
-
-## The rules that are physics (not preference)
-
-1. **Multiplayer-first.** Any state other players can see (positions, physics,
-   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 — 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.
-4. **Never handle tokens or keys.** Login is a browser device flow; platform
-   services (LLM etc.) are already wired through the local shim. If something
-   seems to need an API key, you're on the wrong path.
-5. **Read what's already known before writing game code.** First this game's
-   own **`handbook/`** (its locked truths — qa.md, feel.md, design.md), then
-   the engine craft docs at
-   `node_modules/@looop-games/engine/shared/practices/` — `feel.md`,
-   `architecture.md`, `multiplayer.md`, `qa.md` (and `eval.md` when anything
-   is LLM-generated), which apply to every game.
-   The handbook augments the generic docs; where they touch the same topic,
-   the handbook is this game's answer.
-6. **Anything with an assertion is a regression test.** Playwright checks live
-   in `<aspect>.smoke.mjs` files (excluded from publish, discovered by
-   `looop test`). Keep them; delete only assertion-free scratch.
-
-## This repo's own knowledge
-
-- **`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 `/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`).
-  Nothing under `notes/` is ever published.
-
-<!-- looop:managed:end -->
-
-<!-- Your own instructions go below this line. -->

package/template/CLAUDE.md

@@ -1,4 +0,0 @@
-@AGENTS.md
-
-(If your tool didn't inline the line above: read AGENTS.md — it is this
-project's agent instructions.)

package/template/GEMINI.md

@@ -1,4 +0,0 @@
-@AGENTS.md
-
-(If your tool didn't inline the line above: read AGENTS.md — it is this
-project's agent instructions.)