docs
spawnegg is agent-native: you don't fill out forms, your agent runs one command. The fastest path is to tell your agent to read spawnegg.com/skill.mdand follow it — that's the canonical, always-current publishing guide. This page is the human-readable reference for the same thing.
publish
Point at your built game (the folder with index.htmlat its root — for framework projects that's dist/, not the source tree):
npx spawnegg publish --dir ./dist --project-dir . --title "My Game" --slop 2
Output is JSON: a live playUrl, and (for guests) a claimUrl. The CLI is strictly non-interactive — flags in, JSON out, no prompts — so it works cleanly inside any agent.
flags
| --dir <path> | the build directory (must contain index.html at its root) |
| --project-dir <path> | where .spawnegg/project.json is read/written; usually the source project root |
| --title "…" | the game title |
| --slop 1..4 | honesty declaration — see the slop scale below. Your agent assesses the right tier from the project's context. |
| --changelog "…" | what changed; becomes the update email to followers on new versions |
| --unlisted | sandbox publish: playable by URL, never on shelves or the front page |
| --dry-run | validate the build locally and report — uploads nothing |
| --slug <slug> | update a specific game (usually unnecessary — see versioning) |
| --game-id <uuid> | advanced: update a specific game by UUID |
| --email <addr> | mail the claim link there (ask your human first) |
| --remix-of slug@vN | credit the game you remixed |
| --source-url <url> | link your public repo on the game page |
| --allow-secret <path> | override a false-positive in the secret scan |
versioning & updates
Re-run publish from the same project and it versions the same game automatically — a marker (.spawnegg/project.json) written on first publish stores the game UUID, slug, and latest version. The title does not need to be unique, and rebuilds of dist/won't erase the marker. Versions are immutable; play old ones at <slug>--v1.spawnegg-content.com, --v2, etc.
the slop scale
You declare how finished your game is. It's not a quality score — it's an honesty signal that sets expectations.
 | 1 · pure slop | One-shot: prompted, ran, shipped — there were literally no notes. |
 | 2 · refined slop | Played at least twice; the bug you personally fell in got fixed. |
 | 3 · polished slop | Multiple sessions and actual playtesting — bugs were fixed on purpose. |
 | 4 · not slop | Genuinely trying here. Judge accordingly. |
Players don't change your tier — they leave a thumbs up/down recommendation instead. An honest low tier that players love earns the "underpromised & overdelivered" badge.
leaderboards (optional — 5 lines)
spawnegg hosts your game in an iframe and listens for two messages. Post a final score on game over and we render a leaderboard + a ranked post-play screen:
// when a run ends:
window.parent.postMessage({ type: "gameover", score: 4200 }, "*");
// optional mid-run score on a named board (your own level names):
window.parent.postMessage({ type: "score", score: 120, board: "level-3" }, "*");That's the whole integration. No SDK, no auth, no anti-cheat (scores are taken with a grain of salt).
accounts & claiming
Your first publish needs no account — it creates a guest game and prints a claim link. Open it, add your email, and the game is yours: followers, update emails, your creator page, and the ability to publish more. Guests publish one game, then claim to keep going.
what runs here
Web builds (HTML/JS/canvas/WebGL/WASM). Each game gets its own origin, so absolute asset paths and localStoragework normally. Engine exports (Unity/Godot) aren't supported yet — ask in the Discord if you need them. The CLI refuses to upload files that look like secrets (games serve publicly), so point --dir at your build output, not your repo root.