Make Game

Make Games

When working with a user to create a video game, reference the skills/pipelines/commands provided to help the user create a perfect pipeline for their game development.

Based on the state of the user's request, current codebase, and stage of development, choose the proper steps to take with the user to complete their request.

When to Use

Use this skill when:

• The user is brainstorming or describing a game idea (no project directory required — the idea phase exists exactly for this)
• The current working directory is a game project (has docs/, source files, or an engine config like package.json with Phaser/Three.js, a Unity Assets/, a Godot project.godot, etc.)
• The user wants to add gameplay features, fix gameplay bugs, work on assets, or iterate on game design

Do not use this skill when:

• The user's request is unrelated to game development (general web apps, CLI tools, libraries, infrastructure, data work, etc.)
• The user explicitly asks for a non-game artifact (e.g. "build me a chat app")
• The user wants a one-shot viral game from a tweet, news story, or short prompt — shipped end-to-end in a single session with no milestone planning. Use `/viral-game` instead. That pipeline is opinionated (Phaser/Three.js, here.now, Play.fun) and trades the planning rigor of this skill for ~10-minute time-to-deploy. If a /viral-game session outgrows itself (the user starts asking for milestones, ADRs, or long-term iteration), they should switch back to this skill.

Table of Contents

1. Rules
2. Phases
3. Milestones
4. Important Files
5. Templates
6. Sub-pipelines
7. Other Skills

1. Rules

• No code before plan. If docs/gameplan.md does not exist, you MUST run the idea-phase pipeline to completion — gameplan, docs/tech.md, and ADR-0001 written and user-confirmed — before creating any source files, running engine scaffolders, installing dependencies, or otherwise touching code. A detailed-sounding user prompt is not a substitute for the idea-phase questions: even if the user says "3D racing game with pixel art shaders," you do not yet know the gameplay loop, win condition, controls, scope, or target session length, and improvising those choices is the single biggest cause of refactoring later. Treat this as a hard tripwire — if you find yourself about to scaffold a project without a written gameplan the user has signed off on, stop and run the idea phase first. The clarifying-questions checklist in idea.md is the minimum bar; do not skip items because the prompt "seems clear."
• Always run the [session-start sub-pipeline](sub-pipelines/session-start.md) first when entering a session in an existing project directory. It recovers context (docs/STATE.md, docs/gameplan.md, docs/tech.md, milestones), determines the current phase, and confirms the next step with the user. Skip only if there is no project directory yet (idea-phase brand-new conversation).
• When asking the user questions, use the AskUserQuestion tool. If you can provide some recommendations as multiple choice answers, with the option for the user to provide their own answer, that would be optimal.
• When asking questions, keep them focused, clear, and detailed. If the question may have some logical answers you can think of, provide those as possible answers for the user. This will help if they want to think of a solution themselves as well since they can pull from the different options you provided to curate the perfect answer.
• If you have prior memory or experience with the user, guage their technical ability/expertise, and shape your questions around that. If they do not seem technically advanced, make sure to ask questions in a way they would understand. Offering explanations for more advanced topics along with the question so they aren't answering them blindly.
• Based on the current state of the codebase, the users request, and architectural decisions such as game engine, art style, etc. decide which phase of development the game is in, and start with the pipeline outlined for said phase. They are described in the next section.
• When scaffolding a new project, do not use your embedded knowledge of how to setup the project — many things might have changed since you were trained. Find the newest version of the documentation, or ask the user to find a link and provide it to you. Read the newest installation instructions for the frameworks/libraries you are working with, and follow them according to the stack and setup the project already has set.
• Always prefer the engine's or framework's official scaffolding command over hand-rolling files. Examples: npm create @phaserjs/game@latest for Phaser; npm create vite@latest (then npm install three) for Three.js; Unity's -createProject CLI ("C:\Program Files\Unity\Hub\Editor\<version>\Editor\Unity.exe" -createProject "<path>" -quit on Windows, /Applications/Unity/Hub/Editor/<version>/Unity.app/Contents/MacOS/Unity -createProject <path> -quit on macOS) or Unity Hub's "New project" dialog. For Godot/Unreal, ask the user to create the project from the editor. Hand-written package.json, bundler configs, or engine entry points cause version mismatches the moment a second library is added — do not do it. If you cannot find an official scaffolder and the user cannot point you to one, ask the user to initialize the project themselves and resume the session once it's ready, rather than improvising a setup. Full guidance and per-engine examples live in scaffold.md step 3.
• If the user has a large change to anything regarding core gameplay loop, architecture, etc., ensure that the relevant documentation in the docs/ folder is updated to reflect their changes. For large architecture decisions, we should write to docs/architectural-decisions that can be referenced later with the changelogs. These changelogs must be detailed and include the reason for changing them. The docs/gameplan.md file must also be updated when these decisions are made, with referenced to the AD documents behind the changes.
• After every code change in the development phase, run the [live-iterate sub-pipeline](sub-pipelines/live-iterate.md). It is the canonical real-time verification loop (console → render_game_to_text() → advanceTime() → screenshot if visual → user check). A change is not "done" until it has been iterated on.
• Write failing tests before writing the implementation. Tests are the executable form of acceptance criteria — every checkable AC for the active milestone must have at least one test that asserts it, written first and confirmed to fail for the right reason before any implementation code is touched. Use Playwright (per /qa-game) for gameplay logic and visual baselines; unit tests for pure helpers; multi-client Playwright for multiplayer. Visual/feel AC that can't be meaningfully asserted (juice, polish) must be explicitly marked "verified by user playtest" in the milestone — never silently skipped. If the AC is too vague to write a test against, run playtest / repro first to make it checkable. Loosening a failing test to make it pass is forbidden — fix the implementation, or update the milestone AC and rewrite the test.