# Create a game with Chrona

You are helping the user create and upload a browser game to **https://chrona.world** from Codex or Claude Code. Complete setup and delivery in this conversation. The user only needs to describe their game and approve the browser connection; perform the technical steps yourself.

This guide supplies a self-contained, first-party Skill and Node CLI. Use the exact downloaded CLI for this task, even if another Chrona plugin or MCP server is installed. Do not use another deployment, a remembered test-site default, or a different Chrona integration. No MCP configuration, model API key, new conversation, or client restart is required.

## 1. Prepare the tools

Check for Node.js 20 or later. The kit has no npm dependencies. Use your available download, SHA-256 and ZIP extraction tools (for example Python 3, macOS/Linux unzip, or Windows archive tools). If a required tool is unavailable, explain the specific missing tool rather than claiming setup succeeded.

Download the release metadata and archive from these exact HTTPS URLs:

- Metadata: https://chrona.world/downloads/chrona-game.json
- Archive: https://chrona.world/downloads/chrona-game.zip
- Expected archive SHA-256: `5bc7f085453ac464f9d3debd936020b44b1ef628b499804b6dc582c21417ca70`
- Expected archive size: 66845 bytes

Verify the archive size and SHA-256 before extraction or execution. The metadata must agree with this guide and use the same first-party archive URL. If they disagree, fetch this guide and the metadata again once: a deployment may have changed. Stop if verification still fails. Never execute or unpack an unverified download.

Extract into a new, private cache directory **outside the game project**, using a versioned folder based on the archive digest. Validate that every entry is a regular file or directory under `chrona-game/`; reject absolute paths, `..`, symbolic links and duplicate paths. Never overwrite the user's existing project or custom skills. When reusing a cached kit, verify its files against the validated archive; use a new directory if they differ.

Read the extracted `chrona-game/SKILL.md` and `chrona-game/references/collaboration.md` directly. The CLI is `chrona-game/scripts/chrona.mjs`. In the examples below, replace `CLI` with that **absolute path**, and `PROJECT` with the selected game directory. Do not install the unrelated public plugin as an additional step.

## 2. Connect the user's account

Run the following with the active client name (`Codex` or `Claude Code`):

```sh
node CLI login --site https://chrona.world --remember --client "Codex"
```

The CLI opens Chrona in the user's browser and waits for approval. Ask the user to sign in if needed, check the displayed connection code, and choose **Approve access**. Leave the CLI running while they do this. If automatic browser opening is unavailable, show the exact authorization link printed by the CLI. Do not ask for passwords, cookies or tokens, and do not approve access on the user's behalf.

A successful remembered connection is reused on later runs. Credentials are saved privately outside the project and are never included in uploads. Confirm connection only after the CLI reports `authorized: true`. If approval is declined or expires, explain it and retry only when the user wants to connect. Do not loop or start a World before authorization succeeds.

## 3. Build the game

If the user has not supplied a game idea or an existing project, ask one short question about what they want to build. Then use your normal game creation tools and the user's preferred engine. Preserve the original gameplay, assets and dependencies when uploading an existing project.

Build a playable browser game, run it locally, and inspect the controls, loading and visuals. Fix concrete issues before uploading. Keep complete source, binary assets, package metadata and lockfiles. Do not substitute the optional kit starter for a game the user already has.

Chrona accepts a static browser build with a relative `index.html` entry. Produce a dedicated `dist/` directory:

- For Vite or another bundler, use the project's existing build and lockfile. Set relative asset paths (for example Vite `--base=./`) for delivery.
- For plain HTML/CSS/JS games, copy only the game HTML, scripts, styles and referenced assets into `dist/`. Keep `.chrona`, `.git`, credentials, development tools and dependencies out of that directory. Do not use the entire project root as build output.
- Local backend processes are not deployed by a static upload. If the game needs a backend or an external HTTPS/WSS service, explain the actual requirement and follow the bundled hosting guidance. Do not silently remove features or broaden network access.

## 4. Upload the source and preview

Run these commands yourself after the local game and its build are ready:

```sh
node CLI create --site https://chrona.world --dir PROJECT --name "My game"
node CLI push --site https://chrona.world --dir PROJECT --summary "Upload game source"
node CLI preview --site https://chrona.world --dir PROJECT --dist dist
```

Use the user's chosen game name. `create` binds this project to a World owned by the connected account. Repeating it for an already-bound project reuses that World; subsequent changes use `push` and `preview`. For an uncertain network result, retry the same command before changing source. If the directory is bound to another site or World, stop and explain the mismatch instead of replacing its binding.

The CLI checks source and build hashes, uploads binary assets, and returns the actual preview URL. Open that URL and check the hosted game when browser tools are available. A successful upload is not a gameplay check. If a hosted check is unavailable, say precisely what was tested locally and that the hosted rendering remains unchecked.

Return the preview URL, the World/project link from `create`, and https://chrona.world/worlds.html?tab=mine. State that the source and **private draft preview** were uploaded to the user's account. Treat private preview links as private. Do not invent a public `/worlds/` link or say it is live or listed in Discovery.

## 5. Continue or publish when requested

For further edits, keep the same project and `.chrona/workspace.json`, then push and preview again. Keep the user's working files and connection; do not create another World for each revision.

Uploading a draft and releasing a game are separate. If the user explicitly asks to publish, read the bundled review/release workflow. For an already-created World, obtain publish access with its returned World ID (replace the client name as appropriate):

```sh
node CLI login --site https://chrona.world --world WORLD_ID --publish --client "Codex"
```

Use this World-scoped authorization; a new remembered creation connection does not inherit access to previously created Worlds. Complete `submit`, `review`, `merge` and `publish` for the intended version. Re-check every command result and report the actual playable link and access level. Publishing does not automatically enable public Discovery or grant other users access.

After a branch has been merged, start the next revision with `node CLI branch --site https://chrona.world --dir PROJECT --name "Next update"` before editing. Do not push new work to a merged branch.