Ship your game, the easy way

STAIGE Games — AI Compatibility Prompt

You are preparing my existing game repository for submission to STAIGE Games at `https://games.staige.world`.
Your job is to make the game STAIGE-compatible without redesigning the game, changing gameplay, or unnecessarily rewriting the architecture.
Work directly on the existing project.

## Goal
At the end, I should be able to give STAIGE Games:
* a clean GitHub repository,
* a reproducible build command,
* the correct static/browser build output directory,
* and, only if necessary, a public backend URL for multiplayer/server functionality.

The game must build from a fresh clone, not only from my current machine.

## 1. Understand the game first
Inspect only what is necessary to determine:
* engine/framework,
* browser game vs downloadable/native game,
* singleplayer vs multiplayer,
* static client vs server/backend requirements,
* package manager,
* production build command,
* production output directory,
* required environment variables,
* external assets or files that are currently only available on my machine.

Do not perform a broad architecture audit.
Do not redesign anything.

## 2. Classify the game
Determine which category applies:

### A — Static browser game
Examples:
* Vite
* Three.js
* Phaser
* PixiJS
* plain HTML/CSS/JS
* exported browser/WebGL game

STAIGE should be able to build the repository into static browser files.
Identify the exact:
`BUILD_COMMAND`
and:
`OUTPUT_DIRECTORY`
Do not assume `npm run build → dist`.
Read the actual package scripts, framework configuration and output settings.

### B — Browser game + backend/server
Examples:
* Socket.IO
* WebSockets
* Express
* authoritative multiplayer server
* matchmaking
* API server
* persistent room relay

Separate the architecture into:
static browser client + external backend
The static client must still have its own reproducible build command/output directory.
Determine whether the backend needs:
* a long-running Node/server process,
* Redis,
* database,
* persistent storage,
* WebSocket support,
* CORS/origin restrictions,
* environment variables.

Do not try to force a persistent multiplayer server into static hosting or unsuitable serverless infrastructure.
If one server instance can safely use in-memory state, do not add Redis unnecessarily.

### C — Downloadable/native game
Examples:
* Unity desktop build
* Godot native build
* Unreal
* Electron/native executable

Determine whether the repository can produce a downloadable release reproducibly.
If STAIGE cannot build the native game directly, prepare a GitHub Release workflow or clearly identify the downloadable build artifact expected from the creator.
Do not pretend a native game is a static browser game.

## 3. Clean the repository
Ensure Git excludes anything that should never be published:
* `.env*` containing secrets
* API keys
* private certificates
* private keys
* credentials
* auth tokens
* local HTTPS certificates
* `.vercel/`
* editor caches
* OS files
* temporary QA files
* `node_modules`
* generated build folders unless intentionally required
* machine-specific configuration

Scan the files that will actually be committed for obvious secrets before pushing.
Never print secrets in your response.
Public client-side configuration such as a Vite `VITE_*` URL is allowed only when it genuinely contains no secret.

## 4. Fix asset portability
The game must work from a clean Git clone.
Find:
* absolute local paths,
* missing local assets,
* untracked models/audio/textures,
* files over GitHub's limits,
* build steps that depend on files unavailable in the repository.

Where raw source assets are too large for GitHub, preserve the optimized/runtime assets required to play the game where legally appropriate.
Do not silently remove assets required by the game.

## 5. Check asset licensing
Inspect any available asset/license metadata.
Create or update a concise:
`CREDITS.md`
where attribution is required.
Flag assets with:
* unknown licenses,
* non-commercial restrictions,
* share-alike requirements,
* redistribution restrictions.

Do not block a technical compatibility fix unless necessary, but clearly report licensing concerns to me.
Do not invent licensing information.

## 6. Make the production build reproducible
From a clean environment:
* install dependencies,
* run typecheck where available,
* run existing tests,
* run the actual production build,
* verify the expected output directory exists,
* verify the output contains the files required to launch the game.

Prefer deterministic commands such as:
`npm ci`
when a lockfile exists.
Do not change gameplay merely to make tests pass.

## 7. Multiplayer/backend preparation
Only perform this section if the game genuinely requires a backend.
Ensure the browser client can receive the production backend address through appropriate configuration rather than assuming the backend shares the client origin.
For example, use the framework's public build-time configuration mechanism where appropriate.
The backend must:
* listen on the hosting provider's assigned port,
* expose a minimal health endpoint,
* support HTTPS/WSS in production,
* restrict browser origins appropriately,
* avoid exposing secrets/debug endpoints,
* safely reject invalid room/session requests.

Do not use wildcard production origins unless genuinely necessary.
Account for these STAIGE origins where appropriate:
`https://games.staige.world`
`https://play.games.staige.world`
If the backend requires a long-running process, choose an appropriate host supporting persistent Node/WebSocket services.
Prefer a simple low-cost solution.
Do not introduce Kubernetes or unnecessary infrastructure.
If creating the service requires my login, authorization, payment decision or secret, stop exactly there and give me precise instructions.

## 8. Verify multiplayer if applicable
For multiplayer games, test the real production server where possible:
* secure connection succeeds,
* host can create a room,
* second independent client can join,
* both appear in the same lobby,
* ready state synchronizes,
* realtime state synchronizes,
* disconnect/reconnect behaves correctly,
* invalid room/session credentials fail safely.

Do not fake these results.

## 9. Make the repository understandable to STAIGE
Ensure the repository clearly exposes the real build configuration.
Update the existing README rather than replacing useful documentation.
Add a concise STAIGE Games / Production Build section containing:
* framework/engine,
* install command,
* static/browser build command,
* output directory,
* local development command,
* whether a backend is required,
* production backend configuration variable if applicable,
* multiplayer/server start command if applicable,
* downloadable release information if applicable.

Example:
`Install: npm ci`
`Browser build: npm run build:web`
`Output: dist/client`
`Relay start: npm run start:relay`
Do not write values that are not true for this project.

## 10. GitHub preparation
If this project is not already in Git:
initialize it safely.
If a GitHub repository does not exist, prepare it for one.
For current STAIGE Games V1 compatibility, a public GitHub repository is preferred unless I explicitly tell you private-repository support is available.
Do not delete existing history.
Do not force-push without permission.
Do not commit secrets.

## 11. Do not over-engineer
Do NOT:
* redesign the game,
* change art direction,
* rewrite working gameplay,
* create unrelated features,
* perform repeated broad audits,
* add unnecessary infrastructure,
* add databases/Redis when not required,
* claim security systems that do not exist,
* invent build commands,
* invent hosting URLs,
* fake passing tests.

Make the smallest changes necessary to make the existing game reproducibly compatible with STAIGE Games.

## 12. Final clean-clone test
Before declaring success:
clone/check out the final repository into a fresh directory and confirm that the documented process works using only committed repository files and explicitly documented environment configuration.

## Final response
Give me a compact STAIGE Submission Report:

Compatibility:
Static Browser / Browser + Backend / Downloadable
Repository URL:
`<URL or action required>`
Branch:
`<branch>`
Framework / Engine:
`<detected>`
Install command:
`<command>`
Build command:
`<command>`
Output directory:
`<directory>`
Backend required:
Yes / No
Backend URL:
`<URL / not required / needs deployment>`
Backend start command:
`<command / not applicable>`
Required public client config:
`<names only>`
Required secret server config:
`<names only, never values>`
Tests/build:
`<results>`
Fresh-clone build:
Pass / Fail
Secrets scan:
Pass / Issues found
Licensing warnings:
`<summary>`
Ready for STAIGE Check Repo:
Yes / No
Exact values to enter into STAIGE:
* GitHub repository: `<...>`
* External backend URL: `<... or leave blank>`
* Download/Release URL: `<... or leave blank>`
* Existing Play URL: `<... or leave blank>`

Anything I still need to do manually:
`<only genuine blockers>`

Continue automatically until the game is STAIGE-compatible or you encounter a genuine external authorization/billing decision that requires me.