START HERE before any other spawn tool. The whole workflow in one call: setup order, the art/UI skills to load BEFORE building anything visual, the push → screenshot → fix loop, and the multi-agent rules. Also reports what this project already has (token, variant, game.json, docs) so you know which step you're on. Needs no credentials.

Trade a one-time setup bootstrap key (sbk_…) for a durable agent token. Writes SPAWN_AGENT_KEY to the project .env. The full token is NEVER returned — only a masked prefix. Bootstrap keys expire in ~5 minutes and work once.

Whoami — returns { userId, username } for the connected Spawn agent token.

List games this token can push to: { games: [{ appId, variantId, name, playUrl }] }. Ask the creator which one by name.

Create a new game in the creator's account. Optionally writes SPAWN_VARIANT_ID to .env. Creator should open the play URL and keep it open.

Set SPAWN_VARIANT_ID in the project .env (join an existing game from spawn_list_games).

Scaffold a Spawn game project: gitignore secrets, world/ + scripts/, pull current spec → game.json, materialize scripts, fetch docs into .spawn/ (guide.md, tome-api.md, skills.json).

Fetch engine guide, tome API reference, and skills index. Optionally save under .spawn/. For just the skill menu with descriptions, spawn_skills is cheaper.

The menu of skill ids to pass to spawn_skill, each with what it covers. Browse it when planning a build so the spawn_skill call can carry every domain the work touches — mechanic and look together. Reads .spawn/skills.json when present (no network, no credentials) and falls back to the API. If you already know roughly what you need, skip this and pass ids straight to spawn_skill; a wrong id answers with this list anyway.

Load the craft for what you are about to build — pass EVERY skill the work touches, not one. This is where the engine's real technique lives (how a HUD is actually built, how a material is written, how terrain is sculpted); the API reference only lists fields, so code written without the skills works but looks and behaves like a default. Anything visual should carry the look skills alongside the mechanic: a HUD is game-ui + drawn-art, a glowing surface is custom-materials + looks, a scene is world-composition + looks. Guessing an id is fine and cheap — a miss answers with the real menu.

Pull a saved spec: head (mode=dev, default), published live (mode=live), an exact version, or a published updateSlug. Head pulls sync scripts (untouched fast-forward; both-changed → .theirs) and update the base-version rail — use after version_conflict. Non-head pulls are read-only unless applyLocal:true (resets local rail to that snapshot). version and updateSlug are mutually exclusive.

Compile the project (game.json + world/*.json + scripts/**) and run authoritative server-side schema validation. Schema-valid is not the same as good: it says nothing about how the result looks or feels, which comes from the skills you loaded (spawn_skill) before writing the code.

Compile + push the project live (~1s in the creator's browser). Every push rebuilds the live room. On 409 version_conflict, call spawn_latest then merge .theirs receipts and push again. In team mode pushes are serialised and rebased onto head first, so a 409 is rare and a clean teammate push costs you nothing; a rebase that collides stops the push with your work intact. A successful push proves the spec parsed, nothing more — look at spawn_play_screenshot before calling the work done, and if what you pushed is visual and untextured or plainly styled, the missing piece is a skill you did not load (spawn_skill ids: drawn-art, custom-materials, looks, game-ui).

Run a read-only JavaScript snippet against the live room (e.g. query objects, read an object's state). Pushing is the only write path. Needs a LIVE ROOM — rooms exist only while a player is connected, so open spawn_play_open first or you get a 5xx. api.sql is NOT available here at all (the endpoint is read-only server-side and refuses SQL outright, even SELECT) — there is no way to read the game database through this server.

Variant logs + live room script logs. Use when behavior doesn't match what you pushed.

Active rooms + player counts for the current variant.

Leave background context for Savi (the creator's in-game AI companion) after meaningful pushes so you don't fight over the world.

Revoke the durable agent token (disconnect). Removes SPAWN_AGENT_KEY from project .env after success.

Local project status plus optional remote head/published versions: env (masked), base version, conflict receipts, docs present, headVersion vs publishedVersion when credentials allow.

Open the live Spawn play URL in a local Chromium (Playwright). Headed by default so you can watch. Use this as the agent's eyes/hands on the game — Spawn is WebGPU/canvas, so screenshot + input beat accessibility trees. Resolves play URL from the variant if omitted. Keep it HEADED: headless Chromium has no WebGPU adapter, so Spawn refuses to start and every screenshot shows its 'One graphics fix away' gate instead of the game. The result reports webgpu:'ok'|'unavailable'.

Screenshot the open play session. Primary visual check after spawn_push — look at the image before calling the change done. Judge it as a player would: if it reads as grey boxes, flat untextured shapes, or default browser UI, that is a missing skill rather than a missing feature — load the relevant craft (spawn_skill ids: drawn-art, custom-materials, looks, game-ui, world-composition) and rewrite that code, since none of it is discoverable from the API reference. Optionally save under the project.

Send keyboard/mouse actions to the play session (WASD, jump, click UI, etc.). Clicks the canvas center ONCE per session to give it keyboard focus — later batches send only the actions you list, so no stray clicks fire your weapon or dismiss UI. This is also the ONLY way to click your game's UI (ui.js renders into a cross-origin iframe that spawn_play_eval cannot reach): screenshot first, read the button's position off the image, then click those coordinates. After acting, call spawn_play_screenshot to see the result.

Reload the play tab (e.g. if a push didn't hot-apply to this client). Prefer waiting ~1s after spawn_push first — rooms usually reshape in place.

Return recent browser console / pageerror messages from the play session. Pair with spawn_logs for server-side script errors.

Evaluate JavaScript in the play page's TOP frame (browser context — not the Spawn room api). Use it for page-level diagnostics: WebGPU support, network state, document title. It CANNOT see or click the game's UI: Spawn renders the UI in a cross-origin sandboxed iframe, so document.querySelector finds none of your ui.js buttons and reaching into the frame throws. Click game UI with spawn_play_input coordinates instead, and read live world state with spawn_exec.

Close the Playwright Chromium session.

Whether a play browser session is open, its URL, headed mode, recent error count.

Sync the asset bank with your Spawn ACCOUNT: list every game you own, fetch each one's current server-side spec, and harvest the cdn/ assets it actually uses. This is the authoritative fill — it covers games you have no local checkout of, and assets a teammate or Savi added that never landed on your disk, neither of which a local spawn_asset_scan can see. SLOW BY DESIGN: one spec fetch per game, each carrying every script source, so expect seconds to low minutes on a large account. Run it once to populate an empty bank, and again when the other asset tools say the bank is stale. There is no asset API on Spawn — the specs are the only account-wide record of which assets exist.

Harvest every cdn/ asset path used in a project (or any directory) into the local cross-project asset bank, recording which files and which game use it. Spawn generates an asset on first fetch of its path and keeps it there forever, so the same path in another game is the same asset — but there is no catalog API, and this bank is the only record of which names you have already used and how they turned out. Run it on each of your game projects once, then use spawn_asset_search before inventing a new asset name.

Search the local asset bank for assets you (or your other projects) have already used. Call this BEFORE inventing a new cdn/ asset name: a path that already produced good art is reusable across games verbatim, and a path marked bad tells you what not to spell. Every result reports how many distinct GAMES use it — the strongest signal that an asset actually worked. Pass facets:true with no query to see what categories, kinds and style families the bank holds.

Name, categorize, describe or judge an asset in the bank — including a path that has not been scanned or even used yet. A name is a short handle you can use in place of the path in every other asset tool. This is the memory the platform does not keep: a Spawn asset is generated once from its path and cached there forever, so you cannot re-roll a name, and 'this name produced the wrong thing, use that one instead' is information nothing else records. Write the description while you can still see the asset.

Check whether an asset actually exists on Spawn's CDN, and LOOK AT IT if it is an image (returned inline, so you can judge it rather than guess from the filename). Use it on an unfamiliar path before building around it, and after generating a new one to see what the name produced. Safe to call: it queries the storage host directly, which never triggers generation — a 404 means the asset has not been created yet, not that you are forbidden to ask.