@looop-games/cli 0.1.7 → 0.1.9

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

@@ -1,266 +0,0 @@
----
-name: build
-description: The Looop build loop — the one way game work happens in this repo. Use when the creator wants to make their game, add or change a feature, start something new, or continue where a previous session left off ("let's build", "keep going", "add X", "make it so Y"). Runs from a plan in notes/plans/ — continues the plan if one exists, creates one if not.
----
-
-# /build — the loop that builds this game
-
-You are building for a creator who is probably not a developer. They bring the
-vision and the judgment calls; you bring everything else. This skill is the
-process — one repo, one game, one loop:
-
-> **plan → discuss → build in milestones of auto-verified steps → the creator
-> playtests → offer publish**
-
-Two words carry this loop, sized by the words themselves:
-
-- A **milestone** is a big, vertical increment the creator can actually play —
-  the loop's unit of *their* attention. **The creator playtests at every
-  milestone.**
-- A **step** is a small build increment inside a milestone. **Every step is
-  auto-verified by you** — the creator is never asked to approve steps.
-
-## When to collapse the ceremony
-
-A trivial direct request ("make the ball a bit faster") doesn't need the full
-loop: make the change, verify it, one line in the plan's log if a plan exists.
-The loop is for real increments — new mechanics, features, session-scale work.
-The tell: if the creator will want to *play* the result to judge it, it's a
-milestone and it runs through the loop.
-
-**Collapse never applies when there is no plan yet.** Starting something new
-runs through the §2 discussion — the plan records the creator's answers, so
-it cannot exist before they've answered.
-
-## 1. Anchor on the plan
-
-Every build runs from a **plan** — a file in `notes/plans/`. A build without a
-plan doesn't exist; the plan is the loop's spine and the next session's recap.
-
-- **A plan exists** (look in `notes/plans/`) → CONTINUE it. Read it fully —
-  vision, decisions, the milestone checklist, the log — and pick up exactly
-  where it left off. Don't make the creator repeat themselves.
-- **No plan** → START one (create `notes/plans/<YYYY-MM-DD-HHMM>-<short-name>.md`
-  — creation datetime first, always, so plans list in order and the newest is
-  findable at a glance), through the discussion below. A `/todo` being
-  promoted becomes a plan the same way.
-
-Plan shape (keep it lean — decisions and why, never pasted code):
-
-```markdown
----
-status: in_progress   # in_progress | done | paused | abandoned
-created: YYYY-MM-DD
-updated: YYYY-MM-DD
----
-# <What we're building>
-
-## Vision
-What this wants to be at its best, in the creator's words.
-
-## Decisions
-- **<choice>** — what was decided and why (one entry per real decision).
-
-## Out of scope
-- **<cut>** — why it's out (one line per cut). As load-bearing as Decisions:
-  every "we could also…" that got trimmed lands here, so it stays trimmed.
-
-## Milestones
-### Milestone 1 — <name>  _(playtest: what the creator checks)_
-- [x] step
-- [ ] step
-
-## Log
-- YYYY-MM-DD — what happened, in a few lines. Newest first.
-```
-
-## 2. Discuss before building
-
-Before code, get the shape right with the creator — and record it in the plan.
-
-**Building (§3) runs only from a plan whose decisions are settled — and a
-decision is settled by the creator answering, never by you choosing for
-them.** A new build request therefore starts as a conversation, one decision
-at a time:
-
-- **One decision per turn.** Pose it, resolve it fully, record it in the
-  plan, then move to the next. Never a batch of questions — and never a
-  finished plan (or code, or tests) as your opening move.
-- **Explain the problem before the options.** The creator can't choose
-  between options they don't have the picture for. If they ask "what is X?",
-  stop and explain X cleanly; the decision waits. If they say "I don't
-  understand", don't restate the options louder — back up and re-explain the
-  underlying problem from scratch, with concrete examples.
-- **2–3 options with honest pros/cons, and your lean stated** — make it easy
-  to say "do that" or override you. Don't stack the deck, and don't fake
-  confidence on a genuine 50/50: phrase the case for the other option clearly
-  enough that the creator can pick it up if they disagree.
-- **Lock it in visibly** — say "Locking in: <choice>" and write it into the
-  plan's Decisions as it lands, so the record never lags the conversation.
-
-**Every decision that shapes the game reaches the creator, framed by its
-consequences** — the way an engineer briefs a product manager. Not "authority
-vs. client prediction?" but "if X, joining mid-game is instant but scores can
-briefly disagree; with Y it's the reverse — which matters more here?" Give 2–3
-options with honest trade-offs and your lean. The technical detail stays
-available underneath for whoever pulls the thread.
-
-**Silently decide only what is consequence-free for the creator** — naming,
-file layout, code structure. The test is *"is the creator the right person to
-answer this?"*, not "is this technical?" A technical fork with a consequence
-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
-ask for. Surface extras as explicitly optional, record what was ruled out in
-the plan (an "Out of scope" line per cut), and when a discussion has stacked
-several decisions, recap the accumulated size so the creator can trim.
-
-Then cut the work into **milestones**: each one vertical, end-to-end, playable
-on its own. The FIRST milestone is the thinnest playable thing that proves the
-riskiest idea — if the core bet is wrong, the creator learns it after one
-milestone, not after the whole build. Write the milestones into the plan, each
-with its `_(playtest: …)_` note.
-
-## 3. Build a milestone
-
-Run the steps **autonomously — no approval gates between steps**, just brief
-progress notes:
-
-1. Consult what's already known before writing new systems: `handbook/`
-   (this game's locked truths), the engine practices
-   (`node_modules/@looop-games/engine/shared/practices/`), and `/engine` for
-   components that already exist — don't reinvent a library.
-2. Where a behaviour has a real contract, write the failing test/smoke first,
-   then the code.
-3. **After every step, verify it yourself — run `/qa` on what the step
-   changed.** The steps themselves live in the engine's master QA doc
-   (`node_modules/@looop-games/engine/shared/practices/qa.md`); `/qa` reads
-   and runs them — **including the review rows: fresh sub-agent reviewers
-   (code-quality + test-thoroughness) on the step's diff, findings resolved
-   red→green before the step counts as done.** Every automated step runs at
-   step cadence; only the playtest is per-milestone. You are the only tester
-   inside a milestone — act like it.
-4. **If a fix doesn't land on the first re-test, diagnose — don't
-   second-guess.** Revert it, add instrumentation, find the actual cause;
-   never ship a second guess stacked on the first.
-5. **A real fork discovered mid-step goes to the creator**, framed by its
-   consequences like every other game-shaping decision — never silently
-   resolved just because the build is rolling.
-6. **Never narrow scope silently.** Build the full milestone that was agreed;
-   if a constraint forces something smaller, surface it at the gate — don't
-   quietly ship the lesser version.
-7. Tick the step off in the plan as it lands.
-
-## 3½. Close the milestone — before the creator ever sees it
-
-Every step already passed its own `/qa` — including the per-step review
-sub-agents. The milestone close is the whole-greater-than-parts check before
-the ONE manual gate: run the full **`npx looop test`** suite (everything, not
-just what the last step touched), re-drive the milestone's headline behaviour
-end-to-end yourself, and for anything LLM-authored/generative run the
-**verdict-mix** row (judged scenarios, never a green check). Anything found
-here is fixed **red→green** — the failing test first, then the fix. Only then
-hand back.
-
-## 4. The playtest gate
-
-When the milestone's steps are done and verified, hand it to the creator —
-this is the one place the loop stops for a human:
-
-- **The game is already RUNNING when you hand back — you run the server,
-  never the creator.** If the dev stack isn't up, start it yourself
-  (`npx looop dev`, backgrounded) and confirm the game URL answers before
-  handing over; if one is already running, reuse it. The creator gets a
-  **link to click** — `http://localhost:8000/games/<name>/index.html` (plus
-  the phone/LAN URL when touch is part of the playtest) — never a command
-  to paste. Asking them to run a server is asking them to learn infra.
-- **A minimal checklist of genuinely human-judgment items** — feel, look,
-  "does this play the way you imagined". Never hand them a check you could
-  have run yourself; you already ran those, report the results instead.
-
-Outcomes:
-
-- **It lands** → save it (a commit — `milestone: <name>`), check it off in
-  the plan, update the log, move on. The saves at accepted milestones are the
-  game's restore points.
-- **Close, needs iteration** → adjust within the milestone and hand back.
-- **Wrong direction** → offer the revert plainly, no sunk-cost defence:
-  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 `/handbook` so this
-  class of defect gets an automated check and never reaches a playtest again.
-
-## 5. Offer publish — never publish on your own
-
-After a milestone lands, offer it: `npx looop publish` puts the game live at
-`play.looop.games/g/<name>`. Publishing is **always the creator's explicit
-call** — `/build` never runs it unprompted. For a variant the creator wants to
-compare against the live game, `npx looop publish --slug <alt>` publishes an
-isolated A/B copy (own URL, own room) without touching the real one.
-
-## Parallel lanes (advanced)
-
-A creator can run several `/build` experiments on one game at once. A lane is
-just this loop in a git worktree:
-
-```bash
-# in the main checkout. git worktree needs the repo to have at least one
-# commit (on a never-saved repo it silently creates an EMPTY orphan lane) —
-# this saves ONLY in that case, and is a no-op otherwise:
-git rev-parse HEAD >/dev/null 2>&1 || { git add -A && git commit -m "save: initial"; }
-
-git worktree add ../<name>-<lane>       # one folder per experiment
-cd ../<name>-<lane> && npm install      # node_modules is gitignored — without
-                                        # this, npx falls through to a WRONG
-                                        # public 'looop' package and crashes
-                                        # with a misleading error
-npx looop dev --port 8010               # DISTINCT --port per lane (8010, 8020, …)
-```
-
-- **The lane serves `/games/<worktree-folder-name>/…`** — the folder name, not
-  the original game slug. Use the URL the dev banner prints. The folder name
-  also keys the lane's multiplayer room.
-- Every lane needs its own `--port`: the port shifts the whole stack together
-  — game, multiplayer, services — so lanes are fully isolated (distinct
-  server processes per lane; `looop test` inside one lane picks its own free
-  ports and doesn't disturb the others).
-- Each lane keeps its own plan progress; save/playtest semantics are
-  unchanged inside a lane.
-- Compare lanes live with `publish --slug <lane>` variants.
-- Land the winner: save it in the lane (`git add -A && git commit`), then from
-  the main checkout `git merge <lane-branch>`, then
-  `git worktree remove ../<name>-<lane>` and delete the lane branch.
-- **If the merge conflicts, stop — never auto-resolve.** Show the creator
-  what collided (in game terms: "both lanes changed how jumping feels") and
-  resolve it with them.

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,71 +0,0 @@
----
-name: feedback
-description: File feedback to the Looop team when something in Looop ITSELF seems broken or missing — the engine, a shared component, the looop CLI, login, publishing, the platform. Use the moment you or the creator notice "this looks like a Looop bug, not our game" — 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.
-
-## 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>
----
-# <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.
-
-## 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.)
-
-## 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) 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), the file stays unstamped —
-   just run `npx looop feedback` again later; 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. And a
-missing capability filed from a real game is exactly how the engine decides
-what to build next.

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`.