/new-unity-project

name: new-unity-project
description: Guides creating a new Unity project, gathering concept, platforms, and monetization before setting up the project, source control, and packages. Use when the user asks to start a new game or prototype.
allowed-tools:
  - Bash
  - Write
  - Edit

New Unity Project

A guided flow from an idea to a running, version-controlled Unity project. This skill owns the **flow** — the questions, their ordering, running slow installs in the background while you ask, and the handoffs. It deliberately does **not** re-document commands; it delegates the mechanics to other skills.

**Delegates to (read these for the actual commands — don't reinvent them):**

• **`unity-cli`** — CLI install, auth/license, Editor install, project creation, source control,

opening the project. Its "Bootstrap a new project from scratch" workflow is the backbone here.

• **`unity-package-management`** — installing packages with the Pipeline `package` commands (C# script as the fallback), and

choosing packages by genre / platform / monetization.

• **`urp-postprocessing`**, **`ui`**, **`2d-pixel-perfect`** — the visual baseline (Step 6):

post-processing volume setup, HUD framework choice, pixel-perfect 2D.

• **`implement-in-app-purchases`**, **`levelplay-unity-integration`**, **`build-live-game`** —

monetization / backend *integration* (invoked at the end).

**Work one step at a time.** Ask only the current step's questions and wait for the user before moving on — platform and monetization answers change what you install, so don't gather everything up front or scaffold before they're settled.

Before Step 1: check the delegated skills are loaded

Look for `unity-cli`, `unity-package-management`, `urp-postprocessing` and `ui` in the skills your client lists. The first two carry the commands this flow delegates. Step 6 marks the last two as required. A client that got only this skill won't have the others.

If any is missing, tell the user which one and what it does for them. Offer to install the Unity skills before you start, and don't install without a yes, because it changes their agent setup:

• **Claude Code, with none of the four installed:** `unity setup claude --format json` installs the Unity plugin, which carries all of them. It would duplicate any you already have. An older CLI doesn't know `unity setup`, so use the next route then. A fresh install loads in the next session, or after `/reload-plugins`. Until then, read the skills from the `skillsPath` it reports.
• **Any other case, including a partial set:** ask the user to run `npx skills add Unity-Technologies/skills -g` in their own terminal, which needs Node.js. They pick only the missing skills and their client at its prompts. Don't run it yourself, since its prompts choose where the skills land. If the client reads a skills folder that command doesn't write to, tell the user to copy each missing skill's folder from github.com/Unity-Technologies/skills (under `skills`) into it.

A newly installed skill may not load until the client restarts. If it still isn't listed, ask where the installer put it and read its `SKILL.md` from there.

Don't stall on the two required skills. If the user would rather go on without them, carry on with Step 6's own guidance for that item. Name the missing skill in your final report, so they know the deeper guidance was skipped. The other two carry commands you shouldn't improvise. `unity skill show` prints `unity-cli` without installing it. Without `unity-package-management`, Step 5 can't run, so say so now, before Step 2 starts an Editor install, and let the user decide.

The flow — and where the parallelism is

1. **Concept** — what they're building. 2. **Platforms & monetization** — then, as soon as platforms are known, **kick off the Editor install in the background** (it takes minutes) and keep talking. 3. **(joins)** Editor + platform modules finish installing. 4. **Project + source control** — create from a **URP** template matching 2D/3D; init git. 5. **Packages** — install with the `package add` command once the Editor is open, else the C# script. 6. **Visual baseline** — post-processing, camera, quality tier, UI stack, pipeline-correct shaders, so the first frame doesn't look like an untouched template. 7. **Save & first commit.** 8. **Hand off** monetization / backend.

The whole point of a guided flow over a raw recipe: the multi-minute Editor install overlaps the minutes the user spends answering concept questions, so setup feels instant.

Step 1 — Concept

Ask with your client's multiple-choice question tool if it has one (`AskUserQuestion` in Claude Code, `ask_user` in Copilot CLI, `askQuestions` in VS Code), so the user can pick fast, but let them answer freely too. Without one, ask in plain text. Cover:

• **Genre / core loop** — platformer, top-down shooter, puzzle, idle, RPG, racing, card, tower

defense, sim, hyper-casual, first-person, etc.

• **Dimension & look** — 2D or 3D; art style (pixel, low-poly, stylized, realistic, UI-only).
• **Gameplay** — the one-sentence "what the player does moment to moment."
• **Scope** — single-screen prototype vs. multi-scene game; single-player or multiplayer.

Also settle on a **project name**. Write a 2–4 line **project brief**, read it back to confirm. The brief drives template choice (Step 4), packages (Step 5) and the visual baseline (Step 6): note the palette / mood words the user gives, and whether the look is pixel art.

Step 2 — Platforms & monetization, then start installing

Two decisions, because both change what you install:

• **Target platforms** (multi-select): Desktop (Win/macOS/Linux), Mobile (iOS/Android), WebGL,

Console. These map to Editor **modules** (Step 3) and argue for leaner packages on mobile/WebGL.

• **Monetization**: none / premium / in-app purchases / ads / mix. This only decides which

handoff skill you invoke in Step 8 — don't integrate it now.

Confirm the Editor version to