new-unity-project

Use when starting a brand-new Unity game or project from scratch — "make/start/create a new game", "bootstrap a Unity project", "I want to build a [genre] game", "scaffold/prototype a game", game jam, greenfield, blank project, project setup. A guided flow that gathers the concept, target platforms,

By unity-technologies · 3,259 installs

npx skills add unity-technologies/skills --skill new-unity-project

Source repository · Upstream listing

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 use ( default: latest LTS — see unity cli for the LTS vs. Tech vs. beta trade off). Ask this now , before kicking off the install, so you don't install the wrong one. Then confirm prerequisites and launch the Editor install as a background task so it runs while you continue. See the unity cli skill for exact syntax, module names per platform, and auth / license setup: Run that install as a background task (don't block on it). If you have nothing left to ask, it's fine to just wait — the parallelism only helps when there's a conversation to overlap. Step 3 — Join: Editor ready Before creating the project, confirm the background install finished: If it failed, surface the error (see unity cli troubleshooting) and stop — nothing downstream works without an Editor. Step 4 — Create the project + source control Follow the unity cli "Bootstrap a new project from scratch" workflow verbatim: List the real template ids the Editor offers ( unity templates list type core ) and pick by render pipeline , not just 2D/3D — don't guess ids. Default to URP: com.unity.template.urp blank ("Universal 3D") for 3D, com.unity.template.universal 2d ("Universal 2D") for 2D. com.unity.template.3d / com.unity.template.2d are the Built in Render Pipeline templates — deprecated from Unity 6.5, removed in 6.7 — so choose them only when the user explicitly asks for Built in. Confirm the pick against the JSON renderPipeline field (blank for universal 2d on current releases, so match that one by id). Create with unity projects create "<Name " path <dir editor version <v template <id . Set up source control — ask the user which they want , don't assume: Git (GitHub / GitLab; add git lfs for asset heavy games) or Unity Version Control ( vcs uvcs , which handles large binary assets natively — no LFS), or a purely local git init + Unity .gitignore . Publish in one step with unity projects create vcs … git token from stdin no initial commit (tokens on stdin). Pass no initial commit so the CLI doesn't commit the bare project before packages and .meta files exist — you make the real first commit/check in in Step 7. See the unity cli workflow for exact flags. Step 5 — Packages Map the brief to a concrete package list and install it via the unity package management skill ( never hand edit manifest.json ). Once the Editor is open and ready with com.unity.pipeline (Step 6 installs it), use that skill's package add command. Step 6 opens the Editor, so when the packages must land before the first open, use the skill's C installer script instead (its quit gotcha applies). Read that skill for the genre/platform/monetization → package mapping. The template already provides the render pipeline — never add com.unity.render pipelines.universal to a Built in template project (nothing assigns a URP asset; materials go pink) or vice versa. Read the final list back to the user before installing; verify manifest.json afterward. Step 6 — Visual baseline A fresh template renders correctly but looks like a default: no tonemapping, untouched quality tier, flat colors. Left there, agents reach for OnGUI and guess shader names, which is where washed out or magenta materials come from. Apply this floor before any gameplay work. First, unity pipeline install project path "<project path " , before opening the Editor. Running C in the Editor, and unity command capture screenshot below, both need the project's com.unity.pipeline package. A CLI that predates create adding it by default leaves the project without it (a newer one already added it, and this install then changes nothing), and Step 5 does not add it: that step installs packages by launching the Editor binary with batchmode executeMethod , which never touches the package. Installing before the open is the supported order — the install updates Packages/manifest.json , which Unity reads at project load. Run it against an already open project and either the write fails with PIPELINE MANIFEST WRITE FAILED (ask the user to close the Editor and re run), or it succeeds but the open Editor doesn't load the package until its window regains focus. In the second case unity status reports STATUS PIPELINE LOAD PENDING ; ask the user to switch to the Editor window. Without the package, everything below fails to connect, which looks like the Safe Mode failure unity cli describes but has a different cause. Then unity open "<project path " (also what Step 7 needs), wait until unity status reports the Editor ready, and apply each item below by running C in it. unity cli owns those commands and their syntax — don't re derive them here. Once the Editor is ready, look for unity pipeline in your skills. It is the Pipeline package's own guide, and no client loads it from the package folder. If it is missing, read its SKILL.md now. It sits under .claude/skills/unity pipeline/ in the package: Packages/com.unity.pipeline/ if the project embeds the package, otherwise the Library/PackageCache/com.unity.pipeline@ folder. List Library/PackageCache for the exact name, since the suffix is often a hash, not the version. To have your client load it in later sessions, unity skill install <client local can mirror it, but only for a client with a project scope ( unity skill install list shows which, and Claude Desktop has none). It also writes a project copy of unity cli beside it. The unity cli skill suggests running it once, but here, wait until the user asks, and run it from the project folder after the open. In Claude Code with the Unity plugin installed it stops short, because the plugin already carries unity cli . There, with the user's yes, copy the unity pipeline folder into the project's .claude/skills/ instead. Where no mirror is possible, read the package copy again in each session. Items 1, 2, 5 and 6 assume a URP template , which is the Step 4 default. If the user explicitly chose Built in, don't run them as written: UniversalAdditionalCameraData , Light2D , the urp postprocessing volume framework and every Universal Render Pipeline/ shader are URP types that do not exist there, so the generated C won't compile. On Built in, items 3 and 4 still apply as written, post processing means the le