/make-game

name: make-game
description: Use when the user wants to design, scaffold, build, or iterate on a video game — including brainstorming new game ideas, planning a gameplay loop, choosing an engine, scaffolding a project, adding features, fixing gameplay bugs, or working on assets. Triggers on phrases like "make a game", "create a [genre] game", "build a [type] game", "I want to make a [genre]", or any session inside a game project directory (has docs/, src/, or an engine config).
metadata:
  author: OpusGameLabs
  version: "2.0"
  tags: video games, threejs, unity, gaming, pipelines, commands, godot

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`](../viral-game/SKILL.md) 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](phase-pipelines/idea.md) 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](phase-pipelines/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 o