evolutionary-arcade 0.1.0 → 0.2.0

package/skills/arcade-onboarding/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: arcade-onboarding
+description: Use when a creator wants to put games they already made on Evolutionary Arcade (evolutionaryarcade.com), usually right after they pasted the arcade's prompt into their agent ("help me put my games on Evolutionary Arcade", `arcade guide onboarding`). Walks the first session in Alex's order - vision (what they want, asked all up front), pre-flight (sign-in, tools, the ownership and MIT check) while they're still at the keyboard, then "let me cook": find the games, a fit table with your own time estimates, as-is or optimize, demos and GIFs, one combined dry run and one go, then a ready line with their profile link. Also covers GitHub repos as a source, failures, and the 30-a-day cap.
+---
+
+# Onboarding a creator onto Evolutionary Arcade
+
+## The situation
+
+A creator pasted the arcade's prompt into you. They make browser games with AI, often for a YouTube channel, and they want those games on the arcade with a profile page they can link from their videos. They probably already have several games on their computer or on GitHub.
+
+The arcade is opinionated on purpose. The `arcade` CLI does very little: it validates strictly and publishes. **You do the work**: write `arcade.json`, capture the thumbnail and screenshots from real play, write the controls, record the demo, and bring each game up to the arcade's standard. When the CLI refuses something, its error says exactly what to produce. Do that; don't argue with it and never delete a field to get past a check.
+
+Creators get a high-quality showcase out of this even for games they later publish elsewhere, so do it properly.
+
+What done looks like: the creator's chosen games are live, each with honest metadata, a real thumbnail and screenshots, a demo (and its GIF) if they accepted the offer, and the creator has a line for their video description with their profile link.
+
+## The shape: vision, pre-flight, then let me cook
+
+Every question that needs the creator happens at the start, while they're interested and at the keyboard. Then you work on your own and come back with one thing to approve and a link.
+
+1. **Vision** (step 1): what they want out of the arcade, which games, and their defaults for optimizing and demos.
+2. **Pre-flight** (step 2): sign-in, the tools you'll need, and the ownership check. All the human-in-the-loop setup, done now.
+3. **Let me cook** (steps 3-6): say "I've got it from here. I'll come back with one summary to approve," then do the work.
+4. **One go, then the link** (steps 7-8): the only question while you cook is the publish go, because it makes their games public under their name.
+
+## Ground rules for the whole session
+
+- **One question at a time, each with a default.** Creators are busy. "Want me to ...? (default: yes)" beats an open question.
+- **You never sign in, and never ask for a token or password.** Only the creator approves the sign-in in their browser.
+- **Nothing goes public without their go.** One go covers one batch, after they've seen one combined dry run. If anything changes after that, show it again.
+- **Don't change their system silently.** Installing Node, ffmpeg, or Playwright is their call. Give the one-line command and ask.
+- **Work on copies.** Copy each game to `~/arcade-games/<slug>/` (skip `node_modules`, `.git`, build caches, `.env*`) and work there. Their original folders stay untouched unless they ask you to work in place.
+- **Read `arcade guide <name>` when a step needs it.** The other skills print the same way, with no restart: `building-games` (iframe, CSP, input, saves, leaderboards), `publishing` (arcade.json, media capture, the dry run), `remix-and-blend`.
+
+## Step 0. Install (the prompt already asked for it)
+
+1. `node -v`. It needs 20 or newer. If it's missing or old, tell the creator how to install it (nodejs.org, or `brew install node`) and wait.
+2. `npm i -g evolutionary-arcade`, then `arcade skills install`. Then `arcade guide onboarding` (this file). **Don't ask them to restart you.** The skills are installed for future sessions; in this one you read them with `arcade guide <name>`.
+3. `arcade --version` should say 0.2.0 or newer. If it's older, run the install again.
+
+## Step 1. Vision: what they want
+
+Ask these together, in one message, each with a default, and wait for one reply:
+
+> "Before I set anything up, four quick things:
+> 1. What do you want out of the arcade? A showcase to link from your videos, a place to share with friends, or both? (default: a showcase for your channel)
+> 2. Which games? Tell me where they are (folders or GitHub links), or I can survey your computer for games that look like a good fit. (default: survey)
+> 3. Upload them as they are, or optimize them for the arcade first: touch controls (most YouTube viewers are on phones), gamepad, saved progress, leaderboards? (default: as-is now, optimize later)
+> 4. Want me to play each game and record a short demo? It doesn't take long, and you get a preview and a GIF for sharing. I highly recommend it. (default: yes)"
+
+Their answers are the plan for the rest of the session. Don't ask them again later; mention any change you make to the plan in the final summary.
+
+## Step 2. Pre-flight: sign-in, tools, ownership
+
+Do all the setup that needs them now, before you start cooking.
+
+
+**Sign-in.** Publishing needs it and the browser step is the only part only they can do.
+
+1. `arcade whoami`. If it prints a handle, say "You're signed in as @handle" and continue.
+2. Otherwise run `arcade login` **in the background**. It opens the sign-in page in their browser and prints the link and a code. Tell them:
+   > "I opened the arcade's sign-in page. Sign in (Google, GitHub, Discord, or X), confirm the code `XXXX-XXXX`, and come back here. You'll pick a handle: it's permanent and becomes your profile address, so your channel name is a good choice."
+3. If the browser didn't open (a remote machine, `--no-browser`), give them the printed link.
+4. Keep going with the rest of pre-flight while they sign in. When `arcade login` finishes it prints "Signed in as @handle" and their profile address. Check `arcade whoami` before the dry run. If it's still waiting after ~10 minutes, remind them once; everything up to the dry run can be prepared without it.
+
+**Tools.** If they want demos, check for `ffmpeg` and Playwright now. If one is missing, give the one-line install and ask. Don't install silently. If they asked for a survey, confirm the search scope now (default: home folder, about 4 levels deep).
+
+
+**Ownership.** Say this plainly, once, now:
+
+> "Only publish games you made. Everything on the arcade is open source under MIT, so anyone can play, read, and remix it. Don't upload a game you didn't make unless its license is MIT. Bundled assets (art, music, fonts, libraries) keep their own licenses and must be yours to share."
+
+While you cook, check each game yourself: a non-MIT `LICENSE` at the top of the folder, assets from a store or another game, a copied clone of a commercial game. If something is unclear, ask. Don't publish a game until the creator confirms it's theirs.
+
+When pre-flight is done, say: **"I've got it from here. I'll come back with one summary to approve."** Then cook.
+
+## Step 3. Let me cook: find the games
+
+Use their step-1 answer: the folders or links they named, or a survey within the scope they confirmed.
+
+**Survey (if they say so):** search only where they agree. Default to their home folder, about 4 levels deep, skipping `Library`, `node_modules`, `.git`, `dist`/`build` copies, caches, and cloud-sync folders. Look for `index.html` beside game signs: a `<canvas>`, `requestAnimationFrame`, Phaser, Three.js, PixiJS, Kaboom, Babylon, a `game` in the name. Group hits by project folder. Don't open files that look private (`.env`, keys, documents).
+
+**GitHub links are a source only.** Clone the repo (`git clone --depth 1`) into `~/arcade-games/src/`, then treat it like a local folder: bring it up to the standard and publish with the CLI. There is no direct GitHub publish. If a clone needs credentials, ask them to clone it themselves; never ask for a token.
+
+## Step 4. The fit table
+
+For each candidate, decide from facts, then build one numbered table. It goes in the final summary; the picks are every **ready** and **small fixes** game unless they named specific ones in step 1.
+
+**A good fit for the arcade:**
+- It's a game: input, a loop, and something to do within the first minute. Not a tech demo, a tool, or an unfinished prototype (unless they insist).
+- It runs in a browser from static files, or a build step outputs static files.
+- It needs no server at play time: no multiplayer backend, no API calls, no paid AI API, no login. The arcade's CSP blocks every outside request. CDN imports and web fonts are fine to fix by vendoring them into the folder.
+- It fits: under 50 MB and 800 files, each file under 25 MB, only web file types (`arcade guide building-games` has the list).
+- It's theirs to publish under MIT (step 2).
+
+Verdicts: **ready** (publishes as-is once it has metadata and media), **small fixes** (absolute paths, a CDN import to vendor, a build step, a stray big file), **not a fit** (needs a server, no web build, mostly someone else's work). Give the reason in a few words.
+
+**Time estimates are yours.** Look at the code before you estimate, and say they're estimates. As a starting point: as-is with metadata and media takes you a few minutes per game; touch controls 10-20 min; gamepad 5-10; saves or a leaderboard 5-10 each; a demo 3-5. Adjust for what you see.
+
+```
+#  Game          Where                       Fit          What it needs               As-is / optimized
+1  Neon Drift    ~/games/neon-drift          ready        media, controls text        ~4 min / ~25 min
+2  Tile Tower    github.com/me/tile-tower    small fixes  vendor the Phaser CDN       ~8 min / ~30 min
+3  Mech Arena    ~/proj/mech                 not a fit    needs its websocket server  -
+Publishing: 1, 2 (3 is not a fit)
+```
+
+Up to 30 games publish per day per account (step 7). For a bigger list, publish the strongest first and say so in the summary.
+
+## Step 5. As-is or optimize: do the work
+
+Follow their step-1 answer for the whole batch.
+
+**As-is still meets the standard.** For every game, you:
+- write `arcade.json` (`arcade guide publishing` has a full example): a slug you pick with them (permanent, it's the game's address), the title, a one-or-two-sentence description, exact `controls`, and honest `input` flags;
+- write `LICENSE` (MIT, "Copyright (c) <year> @<handle>") unless they already have an MIT one;
+- run it with `arcade dev`, fix anything that breaks under the arcade's CSP (outside requests, absolute paths);
+- capture a 1280x720 thumbnail mid-action and 2-4 screenshots from real play (`arcade guide publishing`, "Capturing media");
+- fill the Model card with what they tell you (the model and harness they used); leave out anything unknown. Never invent numbers.
+
+**Optimize** adds, per game, only what makes sense for it, using the arcade's format (`arcade guide building-games` has each one):
+- **Touch controls** and `"input": {"touch": true}`: recommend for any game without them. Phones get the game only when touch is on; otherwise they see the demo.
+- **Gamepad** and `"input": {"gamepad": true}`.
+- **Saves** with the `arcade-saves.js` helper and `"profile_saves": true`, for games with progress.
+- **Leaderboards** with `arcade-scores.js` and `"leaderboards"`, for score or time games.
+- Polish the first ten seconds: a clear "click to play", audio that starts on the first click, a pause on blur.
+
+Play every game after you change it. Set an input flag only when that path works end to end.
+
+## Step 6. Demos
+
+If they said yes in step 1 (the default), then for each game: play it with Playwright at 1280x720 against `arcade dev` (drive real inputs, or the game's autopilot if it has one), cut 15-30 s with the action in the first second, save it as `media/demo.mp4`, set `"demo_video"`, and run `arcade media preview`. That makes `media/preview.mp4` (the hover preview) and `media/preview.gif`, and sets both fields. **A game with a demo must have its GIF**; `arcade publish` makes it when it's missing and refuses without ffmpeg. Watch the clips and look at the GIF before moving on. Bot-driven footage is fine; say so in `provenance.notes`. Keep recordings outside the game folder, since everything in it is uploaded. Recording needs Playwright and ffmpeg; if they're missing, ask before installing.
+
+## Step 7. One dry run, one go, publish
+
+1. Run `arcade publish --dry-run --json` in each game folder. Signed out, it runs only the local checks and says to sign in; check `arcade whoami` and wait for the creator if needed.
+2. Exit code 2 means something to fix, and each line says what to produce. Fix it and rerun. If a game still fails after a real attempt, mark it "needs you" and move on.
+3. Show **one** combined summary: for each game, the slug, title, what it becomes (a new game), file count and size, demo yes/no, and every Heads up item. Mention anything you changed in their game.
+4. Ask for one go for the batch: "Publish these N games publicly under @handle, MIT? (yes / list changes)".
+5. On yes, `arcade publish --yes` in each folder, one at a time. If they changed something, change it and show that game's dry run again.
+6. **30 publishes a day** per account. Publish the ones they ranked highest first; tell them the rest will go tomorrow and leave those folders ready.
+
+Failures: a slug that's taken (pick another with them), a game over 50 MB (move recordings and source art out, compress media), a flagged secret (remove it and tell them to rotate it; `--allow-secret` only for keys meant to be public, like a Firebase web key), a network error (rerun; uploads resume). Never retry the same failing thing more than twice.
+
+## Step 8. Hand back the link
+
+1. Ask for their channel URL and a one-line bio, then `arcade profile set --bio "<line>" --link "YouTube <url>"` (pass every link they want; it replaces the list).
+2. `arcade profile show` for the profile address.
+3. Give them a ready line for their video descriptions:
+   > `Play my games (and remix them): https://evolutionaryarcade.com/u/<handle>`
+   and each game's own link (`https://evolutionaryarcade.com/g/<slug>`).
+4. Tell them what happens next: people can play without an account, fork and blend their games, and those remixes show up in each game's family tree. To update a game later, change it in its `~/arcade-games/<slug>/` folder and publish again; that makes the next version.
+
+## Example
+
+Creator: "help me put my games on Evolutionary Arcade." You install, then ask the four vision questions in one message. They want a showcase for their channel, the games are in `~/Desktop/jams`, as-is, and yes to demos. Pre-flight: you start `arcade login` in the background and they approve it in the browser, ffmpeg is already there, Playwright needs one install line and they say yes, and you give the ownership warning. They mention that one game used music from a paid pack. "I've got it from here." You find five games; one needs a websocket server. You copy the four fits, write arcade.json, LICENSE and controls, vendor one CDN import, drop the paid music, capture media, and record four demos (each with its GIF). You come back with one summary (the fit table, what you changed, the combined dry run) and one question: "Publish these 4 publicly under @handle, MIT?" They say yes, four publishes, and you hand them the description line with `/u/<handle>`.

package/skills/arcade-publishing/SKILL.md

@@ -31,9 +31,11 @@ Required: `schema`, `slug`, `title`, `description`, `thumbnail`, and at least on
 - `title` (max 80): what the card shows.
 - `description` (max 2000): what players read before pressing play, and what link unfurls show. Lead with the fantasy and the goal in one or two sentences. Line breaks are kept.
 - `tags` (up to 12, max 30 characters each, lowercased) and `controls` (max 1000): every binding a player needs.
-- `input` and `play`: see `arcade-building-games`. Set an input flag only when that path works end to end, because the site shows badges from them and phones get the demo when `touch` is false.
+- `input` and `play`: see `arcade-building-games`. Set an input flag only when that path works end to end, because the site shows badges from them and phones get the demo when `touch` is false. `tilt` (default `false`) is for games you steer by tilting the phone; it needs `touch` too.
 - `profile_saves` (default `false`): the game saves progress to the player's profile with the `arcade-saves.js` helper. Set it only when the game uses the helper; `arcade-building-games` has the rules.
-- `thumbnail` and `screenshots` (1 to 12) are .png, .jpg, or .webp. `demo_video` and `preview_video` are .mp4 or .webm. Every path is relative to the folder, with no `..`.
+- `leaderboards` (up to 4, default none): global leaderboards the game posts to with the `arcade-scores.js` helper. Each has an `id`, a `label`, and a `max`, and the dry run lists them with their limits. `arcade-building-games` has the rules.
+- `thumbnail` and `screenshots` (1 to 12) are .png, .jpg, or .webp. `demo_video` and `preview_video` are .mp4 or .webm. `preview_gif` is a .gif cut from the demo, required whenever there's a demo; `arcade media preview` (or `arcade publish`) makes it. Every path is relative to the folder, with no `..`.
+- `license` (optional): every game on the arcade is open source under MIT, so leave it out or set it to `"MIT"`. Anything else fails validation. The folder's `LICENSE` names the creator ("Copyright (c) <year> @handle"); if `arcade new` wrote it before you logged in, `arcade publish` fills in the handle. A license file at the top of the folder (`LICENSE`, `LICENSE.md`, `COPYING`, and the like) that isn't MIT stops the publish; other people's licenses go in `licenses/<name>/` or beside their code.
 - `lineage`: the CLI writes it. Don't edit it.
 - `provenance`: the Model card.
 
@@ -77,7 +79,7 @@ Everything in `provenance` is optional, and the site labels build stats "creator
 - `orchestrator`: `model` (required once you include `orchestrator`), `model_id`, `harness`, and `tokens`. `subagent_models`: one entry per model, with an optional `count` and `tokens`. Leave the list empty if the orchestrator did everything.
 - `tokens`, as integers: `input` is uncached input plus cache writes, `cached_input` is cache reads, and `output` is output. Once you include `tokens`, both `input` and `output` are required. If your harness counts cached tokens inside its input total, subtract them so nothing is counted twice.
 - `build`: `cost_usd`, `wall_time_minutes`, and `cost_basis` (`api-equivalent` for what the tokens would cost at API prices, or `billed` for what you paid).
-- Extra fields you add, such as `engine` or `tools`, are kept verbatim. Keep the whole block under 256 KB.
+- Extra fields you add, such as `engine` or `tools`, are kept verbatim, except `github`: the arcade sets that itself when it publishes from a GitHub repo, and drops it from uploads. Keep the whole block under 256 KB.
 
 Hard rules:
 - **Never invent a number.** Leave out any key you don't know. Don't write `null`, an empty string, or `0`. `null` fails validation. An empty prompt or notes counts as not shared, so leave the key out. `0` publishes a made-up number.
@@ -114,7 +116,7 @@ ffmpeg -ss 4 -i ../rec/<file>.webm -t 24 -an -vf scale=1280:720 \
 - **Thumbnail:** pick the best candidate and copy it to `media/`. It must be a real in-game frame at 16:9 (the card crops anything else). No title card and no added text.
 - **Screenshots:** two to four different moments, such as the core action, a quiet good-looking moment, the HUD under pressure, and the end screen.
 - **Demo:** 15 to 30 seconds of real gameplay, at 1280x720, in H.264 mp4 or webm. No audio is needed. Use `-ss` to skip the title screen, so action starts in the first second or two.
-- **Preview: remake it every time you make a new demo.** Run `arcade media preview`. It cuts the first 12 s of `demo_video`, overwrites `media/preview.mp4`, and sets `preview_video`. `arcade publish` makes a preview only when `preview_video` is empty, and a folder from `arcade pull`, `fork`, or `regen` arrives with the parent's `preview_video` already set (a regen has the path but not the file, so publish exits 2 until you make one). After your first publish it stays set too. The preview plays muted, loops, and restarts on every hover, so those 12 seconds are the pitch. Watch it. If it misses the best moment, re-cut the demo with a later `-ss` and run the command again.
+- **Preview and GIF: remake them every time you make a new demo.** Run `arcade media preview`. It cuts the first 12 s of `demo_video` into `media/preview.mp4` and the first 6 s into a looping `media/preview.gif` (under 5 MB, for "someone remixed your game" emails and link previews), and sets `preview_video` and `preview_gif`. `arcade media gif` remakes only the GIF. A game with a demo can't publish without its GIF. `arcade publish` makes the preview only when `preview_video` is empty, and the GIF only when `preview_gif` is empty (the dry run warns when either is older than the demo), and a folder from `arcade pull`, `fork`, or `regen` arrives with the parent's `preview_video` already set (a regen has the path but not the file, so publish exits 2 until you make one). After your first publish it stays set too. The preview plays muted, loops, and restarts on every hover, so those 12 seconds are the pitch. Watch it. If it misses the best moment, re-cut the demo with a later `-ss` and run the command again.
 - **Budget:** the whole upload must stay under 50 MB and 800 files. The thumbnail and each screenshot must be at most 5 MB, and the demo, preview, and any other file at most 25 MB. A 24-second demo at CRF 23 is about 8 MB.
 - **Look at every file** before you publish. For video, a contact sheet is quick: `ffmpeg -i media/demo.mp4 -vf fps=1/3,scale=320:-1,tile=4x3 -frames:v 1 ../rec/sheet.png` (one image, covering 36 s). If headless WebGL renders black, run headed or pass GPU flags to Chromium (on macOS the seeds used `--use-angle=metal --ignore-gpu-blocklist`).
 
@@ -122,10 +124,12 @@ ffmpeg -ss 4 -i ../rec/<file>.webm -t 24 -an -vf scale=1280:720 \
 
 Run `arcade publish --dry-run` and read all of it. It uploads nothing, but know what it is:
 
-- It needs `arcade login` and a network connection, because the arcade checks the upload before anything is listed. Problems the arcade finds (a file over 25 MB, too many files, a slug that's taken, a stale base) exit before the file list prints.
-- It may make `media/preview.mp4` and write `preview_video` into arcade.json.
+- Signed out, it runs only the local checks (arcade.json, file types, license, media, secrets), prints any Heads up, and exits 1 asking you to sign in. The full dry run needs `arcade login` and a network connection, because the arcade checks the upload before anything is listed. Problems the arcade finds (a file over 25 MB, too many files, a slug that's taken, a stale base) exit before the file list prints.
+- Every problem it exits 2 on says what to produce: a missing thumbnail names the size and path to capture, a missing arcade.json lists the fields to write.
+- It may make `media/preview.mp4` and `media/preview.gif` and write `preview_video` and `preview_gif` into arcade.json.
 - It lists the first 40 files, then "…and N more", but files inside hidden folders (like `.claude/`) are always listed. New files are tagged `new`. Review the whole tree yourself: `find . -type f -not -path './node_modules/*' -not -path './.git/*'`.
 - It follows symlinks only when they point inside the folder. Anything else is listed as skipped, and never uploaded.
+- It says "Published games are open source under MIT" under the action line. Anything bundled from others keeps its own license and must be the user's to share.
 - Its **Heads up** list flags likely mistakes without stopping the publish: a leftover `parents/`, `BLEND.md` or `PROMPT.md`, media already on the arcade on a fork, blend, or regen (so probably the parent's), starter text, a placeholder slug, a home-folder path in the prompt or notes, a thumbnail over 500 KB, and no model or prompt on the Model card. Fix each one, or tell the user why it's fine.
 - Its Model card shows the model, tokens, cost, time, process, and the prompt's length, not the prompt or notes text. Read those in arcade.json.
 
@@ -147,6 +151,10 @@ After an original, fork, blend, or update publishes, the CLI rewrites the folder
 
 **Generation ids, for `arcade main <slug> <generation>`:** `arcade info <slug>` lists every generation id and marks the main one. After a non-regen publish, the new id is also in `lineage.based_on.generation`. A regen doesn't become the main one on its own; its publish prints the exact `arcade main` command for the owner.
 
+## Games on GitHub
+
+A GitHub repo is a source, not a way to publish. Clone it (`git clone --depth 1 <url>`) into a working folder, bring it up to the arcade's standard like any other game (arcade.json, LICENSE, media from real play, a demo and its GIF), and publish it with `arcade publish`. Only publish a repo the user made, or one under MIT. If the clone needs credentials, ask the user to clone it; never ask for a token.
+
 ## Taking a game down
 
 `arcade unpublish <slug>` takes your game down, and `arcade republish <slug>` brings it back. The slug stays yours and is never reused. Unpublishing doesn't un-leak anything: if a secret shipped, unpublish, then rotate the secret right away, because public source may already have been copied.

package/skills/arcade-remix-and-blend/SKILL.md

@@ -27,7 +27,7 @@ A good remix is clearly related to its parent and clearly earns its own place:
 - People who loved the original still find what they loved, unless changing that was the point.
 - Something meaningful is different, and the page says what. `provenance.prompt` holds this step's prompt, and `provenance.notes` says what you kept, what you changed, and why.
 - Lineage is exactly what the CLI wrote.
-- The title, description, controls, media, and model data describe your game, not the parent's. For a regen, the game's slug, title, description, tags, and controls stay the owner's. What's yours is the build, its media, its input flags and `profile_saves`, and its provenance.
+- The title, description, controls, media, and model data describe your game, not the parent's. For a regen, the game's slug, title, description, tags, and controls stay the owner's. What's yours is the build, its media, its input flags, `profile_saves` and `leaderboards`, and its provenance.
 
 This matters because lineage is the arcade's memory. Following the prompts and notes from a game back through its parents should tell the story of how it evolved. Wrong lineage erases someone's credit, and a vague note wastes the one place a stranger learns what your version is.
 
@@ -50,7 +50,7 @@ Contrasting cases:
 
 1. **Always start from the command.** Run `arcade pull`, `fork`, `blend`, or `regen` before you write any code. The CLI pins lineage to the exact generation ids it downloaded, so a game you publish hours later still records what it was really built from. If you paste a parent's code into an `arcade new` folder, you publish an uncredited copy.
 2. **Never hand-edit `lineage`.** Don't type ids, add or drop parents, change `kind`, or delete the block. Deleting it doesn't make a game original in any honest way: on your own slug it silently becomes an update of the main generation, and on a new slug it becomes an uncredited original. If the plan changes (a fork picks up a second parent, a regen starts borrowing code, a blend stops using a parent), run the right command into a fresh folder and move your work across. A lineage that doesn't fit its kind fails the local check, and `arcade publish` exits 2. The arcade can also reject a publish the local check can't see, such as a stale base, a slug that's taken, or a base that isn't live. Those exit 1 with a message saying what to fix. Fix them by re-running the command, not by editing ids.
-3. **Credit is automatic. Don't strip it.** The game page shows the "forked from" or "blended from" link with every parent. You don't need to write credits, but don't remove any. If a parent has `LICENSE` or `NOTICE` files, keep them (a fork has them where the parent put them; a blend has them under `parents/`, so move them out before you publish, see Blending).
+3. **Credit is automatic. Don't strip it.** The game page shows the "forked from" or "blended from" link with every parent. You don't need to write credits, but don't remove any. Every game here is MIT, and MIT asks that a parent's notice stays with its code. `arcade fork` moves the parent's `LICENSE` to `licenses/<slug>/` and writes yours at the top; keep both. A blend has each parent's under `parents/`, so move them out before you publish (see Blending). Keep any `NOTICE` files too.
 4. **Make the provenance yours.** Whatever the download leaves in `provenance`, it must describe your build when you publish: your prompt for this step, your orchestrator model and harness, your subagent models, your cost and time. The parent's numbers already sit on the parent's page. Everything in `provenance` is public, so write it for a stranger.
 5. **Capture your own media.** A fork arrives with the parent's media files. A blend or regen arrives with media paths in `arcade.json` but no files of your own, and `arcade publish` exits 2 until every path points at a real file. For every fork, blend, and regen, capture new media from your build. For an update, refresh it if the game looks different. A card that shows the parent's footage misrepresents what players will get.
 6. **Keep the slug for updates and regens. Choose a new one for forks and blends.** A slug is permanent and becomes the game's subdomain. `arcade fork` and `arcade blend` both write a placeholder slug nobody has taken yet (a fork gets `<parent>-remix`, a blend `<a>-x-<b>`, with `-2` or `-3` added if needed). Replace it with one that names your game.
@@ -82,7 +82,7 @@ Then change something meaningful, keep what made the original good unless that's
 - **Be honest about steering.** Regen downloads the kickoff prompt only, not the original's `prompt_log`. If the original was iterated and its page shows later prompts, you can replay them in order. Anything past the kickoff prompt, replayed or your own, goes in `prompt_log` with `process: "iterated"`, and `notes` says so. Hand steering is fine. Hiding it breaks the comparison.
 - **Note the model differences.** In `notes`, say which model and harness you used, what came out differently, where it struggled, and what you fixed by hand.
 - **Point `play` at your build.** The regen `arcade.json` keeps the original's `play` setting. If your build lives somewhere else, change it.
-- **Saves are yours to add.** `arcade regen` leaves out `profile_saves`, because none of the original's code comes along. If the original saves players' progress, `PROMPT.md` says so. To save it in your build, use `arcade-saves.js` with a key of your own (see Profile saves in `arcade-building-games`) and set the flag. Players' profiles open to your regen once the owner makes it main, or right away if you're the owner. Until then it plays from the device, so it can't touch anyone's saved progress.
+- **Saves are yours to add.** `arcade regen` leaves out `profile_saves`, because none of the original's code comes along. If the original saves players' progress, `PROMPT.md` says so. To save it in your build, use `arcade-saves.js` with a key of your own (see Profile saves in `arcade-building-games`) and set the flag. Players' profiles open to your regen once the owner makes it main, or right away if you're the owner. Until then it plays from the device, so it can't touch anyone's saved progress. Leaderboards work the same way: `arcade regen` leaves out `leaderboards`, `PROMPT.md` names the original's boards, and to post to them use `arcade-scores.js` with the same board ids (see Leaderboards in `arcade-building-games`).
 - **No prompt, no regen.** Prompts are optional, and some games don't share one. `arcade regen` then stops with an error. Fork the game or make an original.
 
 Your generation lands in the stack of the version you regenerated, even if the game has since moved to a later version, and it shows on your profile. It doesn't become the main one. The owner decides with `arcade main <slug> <generation>`, and if you're the owner, that's you.