Game Engine Setup

When this skill is invoked:

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys workflow

Tier awareness. The workflow tier resolved above governs which design artifact this skill expects and the finish path it recommends in §12:

• minimal — the design artifact is the one-page design/game-brief.md (no GDDs, systems decomposition, or per-system design at this tier). /setup-engine runs first in the minimal path, so a missing brief here is normal, not a gap. The finish path is the 4-step floor.
• standard / full — the design artifact is design/gdd/game-concept.md and the finish path is the full pipeline.

If the block did not render (shell preprocessing disabled), assume minimal (the default).

1. Parse Arguments

Four modes:

• Full spec: /setup-engine godot 4.6 — engine and version provided
• Engine only: /setup-engine unity — engine provided, version will be looked up
• No args: /setup-engine — fully guided mode (engine recommendation + version)
• Refresh: /setup-engine refresh — update reference docs (see Section 10)
• Upgrade: /setup-engine upgrade [old-version] [new-version] — migrate to a new engine version (see Section 11)

2. Guided Mode (No Arguments)

If no engine is specified, run an interactive engine selection process:

Check for existing game concept

Read the design artifact for the resolved tier (see Tier awareness above):

• standard / full: read design/gdd/game-concept.md if it exists — extract genre, scope, platform targets, art style, team size, and any engine recommendation from /brainstorm.

• minimal: read design/game-brief.md if it exists — extract genre, scope, platform, and art direction from its fields. Its absence is expected at minimal (the brief is authored after engine setup in the minimal path), so do not treat a missing brief as a gap — proceed straight to guided selection.

• If no concept or brief exists, inform the user:

  "No game concept found. Consider running /brainstorm first to discover what you want to build — it will also recommend an engine. Or tell me about your game and I can help you pick."

  (At minimal this is optional, not a prerequisite — you can pick an engine now and write the brief next.)

If the user wants to pick without a concept, ask in this order:

Question 1 — Prior experience (ask this first, always, via AskUserQuestion):

• Prompt: "Have you worked in any of these engines before?"
• Options: Godot / Unity / Unreal Engine 5 / Multiple — I'll explain / None of them
• If they pick a specific engine → recommend that engine. Prior experience outweighs all other factors. Confirm with them and skip the matrix.
• If "None" or "Multiple" → continue to the questions below.

Questions 2-6 — Decision matrix inputs (only if no prior engine experience):

Question 2 — Target platform (ask this second, always, via AskUserQuestion — platform eliminates or heavily weights engines before any other factor):

• Prompt: "What platforms are you targeting for this game?"
• Options: PC (Steam / Epic) / Mobile (iOS / Android) / Console / Web / Browser / Multiple platforms
• Platform rules that feed directly into the recommendation:
  • Mobile → Unity strongly preferred; Unreal is a poor fit; Godot is viable for simple mobile
  • Console → Unity or Unreal; Godot console support requires third-party publishers or significant extra work
  • Web → Godot exports cleanly to web; Unity WebGL is functional; Unreal has poor web support
  • PC only → all engines viable; other factors decide
  • Multiple → Unity is the most portable across PC/mobile/console

1. What kind of game? (2D, 3D, or both?)
2. Primary input method? (keyboard/mouse, gamepad, touch, or mixed?)
3. Team size and experience? (solo beginner, solo experienced, small team?)
4. Any strong language preferences? (GDScript, C#, C++, visual scripting?)
5. Budget for engine licensing? (free only, or commercial licenses OK?)

Produce a recommendation

Do NOT use a simple scoring matrix that eliminates engines. Instead, reason through the user's profile against the honest tradeoffs below, then present 1-2 recommendations with full context. Always end with the user choosing — never force a verdict.

Engine honest tradeoffs:

Godot 4

• Genuine strengths: 2D (best in class), stylized/indie 3D, rapid iteration, free forever (MIT), open source, gentlest learning curve, best for solo devs who want full control
• Real limitations: 3D ecosystem is thin compared to Unity/Unreal (fewer tutorials, assets, community answers for 3D-specific problems); large open-world 3D is very hard and largely untested in Godot; console export requires third-party publishers or significant extra work; smaller professional job market
• Licensing reality: Truly free with no revenue thresholds ever. MIT license means you own everything.
• Best fit: 2D games of any scope; stylized/atmospheric 3D; contained 3D worlds (not open-world); first game projects where learning curve matters; projects where budget is a hard constraint at any scale

Unity

• Genuine strengths: Industry standard for mid-scope 3D and mobile; massive asset store and tutorial ecosystem; C# is a professional language; best console certification support for indie; strong community for almost every genre
• Real limitations: Licensing controversy in 2023 damaged trust (runtime fee was proposed then walked back — the risk of policy changes remains real); C# has a steeper initial curve than GDScript; heavier editor than Godot for simple projects
• Licensing reality: Free under $200K revenue AND 200K installs (Unity Personal/Plus). Only becomes costly if the game is genuinely successful — most indie games never hit this threshold. The 2023 controversy is worth knowing about but the actual current terms are reasonable for most indie developers.
• Best fit: Mobile games; mid-scope 3D; games targeting console; developers with C# background; projects needing large asset store; teams of 2-5

Unreal Engine 5

• Genuine strengths: Best-in-class 3D visuals (Lumen, Nanite, Chaos physics); industry standard for AAA and photorealistic 3D; large open-world support is mature and production-tested; Blueprint visual scripting lowers C++ barrier; strong for games targeting high-end PC or console
• Real limitations: Steepest learning curve; heaviest editor (slow compile times, large project sizes); overkill for stylized/2D/small-scope games; C++ is genuinely hard; not suitable for mobile or web; 5% royalty past $1M gross revenue
• Licensing reality: 5% royalty only applies AFTER $1M gross revenue per title. For a first game or any game that doesn't reach $1M, it costs nothing. This threshold is high enough that most indie developers will never pay it.
• Best fit: AAA-quality 3D; large open-world games; photorealistic visuals; developers with C++ experience or willing to use Blueprint; games targeting high-end PC/console where visual fidelity is a core selling point

Genre-specific guidance (factor this into the recommendation):

• 2D any style → Godot strongly preferred
• 3D stylized / atmospheric / contained world → Godot viable, Unity solid alternative
• 3D open world (large, seamless) → Unity or Unreal; Godot is not production-proven for this
• 3D photorealistic / AAA-quality → Unreal
• Mobile-first → Unity strongly preferred
• Console-first → Unity or Unreal; Godot console support requires extra work
• Horror / narrative / walking sim → any engine; match to art style and team experience
• Action RPG / Soulslike → Unity or Unreal for 3D; community support and assets matter here
• Platformer 2D → Godot
• Strategy / top-down / RTS → Godot or Unity depending on 2D vs 3D

Recommendation format:

1. Show a comparison table with the user's specific factors as rows
2. Give a primary recommendation with honest reasoning
3. Name the best alternative and when to choose it instead
4. Explicitly state: "This is a starting point, not a verdict — you can always migrate engines, and many developers switch between projects."
5. Use AskUserQuestion to confirm: "Does this recommendation feel right, or would you like to explore a different engine?"
   • Options: [Primary engine] (Recommended) / [Alternative engine] / [Third engine] / Explore further / Type something

If the user picks "Explore further": Use AskUserQuestion with concept-specific deep-dive topics. Always generate these options from the user's actual concept — do not use generic options. Always include at minimum:

• The primary engine's specific limitations for this concept (e.g., "How far can Godot 3D actually go for [genre]?")
• The alternative engine's specific tradeoffs for this concept
• Language choice impact on this concept's technical challenges
• Any concept-specific technical concern (e.g., adaptive audio, open-world streaming, multiplayer netcode)

The user can select multiple topics. Answer each selected topic in depth before returning to the engine confirmation question.

3. Look Up Current Version

Once the engine is chosen:

• If version was provided, use it
• If no version provided, use WebSearch to find the latest stable release:
  • Search: "[engine] latest stable version [current year]"
  • Confirm with the user: "The latest stable [engine] is [version]. Use this?"

Check the chosen version against what is actually installed

A version found by web search is what exists, not what the developer has. Pinning one they cannot run means every later instruction — build, test, smoke, the engine reference docs — targets an engine that is not on the machine.

Probe for the binary (Bash), and treat failure as unknown, never as absent:

Keep the executable the probe found (for Godot, whether bare godot --version ran — that is, godot is on PATH): Section 5.5.1 writes it into commands.* and engine.path.

Then:

• Match — say so in one line and continue.
• Mismatch — state both versions and ask, offering three options: pin the installed version, pin the newer one and upgrade later, or pin the newer one deliberately. Record the answer; do not pick silently.
• Not found / probe failed — report installed version NOT DETERMINED and continue with the chosen version. Do not report this as "no engine installed": a probe that could not run has not established absence.

Whatever the outcome, write it into Section 7's VERSION.md as an Installed at pin time row, so a later reader can tell a deliberate version-ahead pin from an accident.

4. Update CLAUDE.md Technology Stack

Language Selection (Godot only)

If Godot was chosen, ask the user which language to use before showing the proposed Technology Stack:

"Godot supports two primary languages:

A) GDScript — Python-like, Godot-native, fastest iteration. Best for beginners, solo devs, and teams coming from Python or Lua. B) C# — .NET 8+, familiar to Unity developers, stronger IDE tooling (Rider / Visual Studio), slight performance advantage on heavy logic. C) Both — GDScript for gameplay/UI scripting, C# for performance-critical systems. Advanced setup — requires .NET SDK alongside Godot.

Which will this project primarily use?"

Record the choice. It determines the CLAUDE.md template, naming conventions, specialist routing, and which agent is spawned for code files throughout the project.

Primary Language (Unreal)

If Unreal was chosen, ask via AskUserQuestion: "Will most gameplay logic live in C++ or in Blueprints?" — [A] C++ (Blueprints for tuning and prototyping) / [B] Blueprint-primary (C++ only where needed). Default to C++ if the user has no preference. The answer sets engine.language ("C++" or "Blueprint").

Read CLAUDE.md and show the user the proposed Technology Stack changes. Ask: "May I write these engine settings to CLAUDE.md?"

Wait for confirmation before making any edits.

Update the Technology Stack section, replacing the [CHOOSE] placeholders with the actual values:

For Godot — use the template matching the language chosen above. See .claude/skills/setup-engine/references/godot-language-config.md (A1) for all three variants (GDScript, C#, Both).

For Unity:

- **Engine**: Unity [version]
- **Language**: C#
- **Build System**: Unity Build Pipeline
- **Asset Pipeline**: Unity Asset Import Pipeline + Addressables

For Unreal:

- **Engine**: Unreal Engine [version]
- **Language**: [C++ (primary), Blueprint (gameplay prototyping) | Blueprint (primary), C++ where needed]
- **Build System**: Unreal Build Tool (UBT)
- **Asset Pipeline**: Unreal Content Pipeline

The Language line follows the primary-language answer above: the first form for [A] (engine.language: "C++"), the second for [B] ("Blueprint").

Engine reference import

In the same CLAUDE.md write, set the Engine Version Reference import to the chosen engine. Find the line marked ENGINE-REFERENCE-IMPORT (an @docs/engine-reference/<engine>/VERSION.md line under its comment) and Edit it to point at the configured engine:

• Godot → @docs/engine-reference/godot/VERSION.md
• Unity → @docs/engine-reference/unity/VERSION.md
• Unreal → @docs/engine-reference/unreal/VERSION.md

This is why a fresh Unity or Unreal project no longer loads the Godot reference in every session. It is idempotent — re-running /setup-engine for a different engine rewrites the same line. (The target docs/engine-reference/<engine>/ directory is created in Section 8 below if it does not yet exist.)

5. Populate Technical Preferences

After updating CLAUDE.md, create or update .claude/docs/technical-preferences.md with engine-appropriate defaults. Read the existing template first, then fill in:

Engine & Language Section

• Fill from the engine choice made in step 4

Naming Conventions (engine defaults)

For Godot — see .claude/skills/setup-engine/references/godot-language-config.md (A2) for GDScript, C#, and Both variants.

For Unity (C#):

• Classes: PascalCase (e.g., PlayerController)
• Public fields/properties: PascalCase (e.g., MoveSpeed)
• Private fields: _camelCase (e.g., _moveSpeed)
• Methods: PascalCase (e.g., TakeDamage())
• Files: PascalCase matching class (e.g., PlayerController.cs)
• Constants: PascalCase or UPPER_SNAKE_CASE

For Unreal (C++):

• Classes: Prefixed PascalCase (A for Actor, U for UObject, F for struct)
• Variables: PascalCase (e.g., MoveSpeed)
• Functions: PascalCase (e.g., TakeDamage())
• Booleans: b prefix (e.g., bIsAlive)
• Files: Match class without prefix (e.g., PlayerController.h)

Input & Platform Section

Populate ## Input & Platform using the answers gathered in Section 2 (or extracted from the game concept). Derive the values using this mapping:

For Primary Input, use the dominant input for the game genre:

• Action/RPG/platformer targeting console → Gamepad
• Strategy/point-and-click/RTS → Keyboard/Mouse
• Mobile game → Touch
• Cross-platform → ask the user

Genre may not exist yet — check before deriving from it. At minimal the design artifact is design/game-brief.md, and it is authored after this skill runs (Section 2 says so explicitly). There is no genre to map. The same is true at any tier when /setup-engine is run before the concept exists.

When genre is unavailable, ask — do not infer one from the platform, and do not leave the field silently blank:

• Prompt: "Primary input for a [2D/3D] [platform] game? Genre isn't established yet — the brief comes next — so this can't be derived."
• Options: the plausible inputs for that platform, plus Leave as [TO BE CONFIGURED] — a legitimate answer here, revisited via /settings once the brief exists.

Gamepad Support and Touch Support still come from the platform table above; only Primary Input depends on genre.

Present the derived values and ask the user to confirm or adjust before writing.

Example filled section:

## Input & Platform
- **Target Platforms**: PC, Console
- **Input Methods**: Keyboard/Mouse, Gamepad
- **Primary Input**: Gamepad
- **Gamepad Support**: Full
- **Touch Support**: None
- **Platform Notes**: All UI must support d-pad navigation. No hover-only interactions.

Remaining Sections

• Performance Budgets: Use AskUserQuestion:
  • Prompt: "Should I set default performance budgets now, or leave them for later?"
  • Options: [A] Set defaults now (60fps, 16.6ms frame budget, engine-appropriate draw call limit) / [B] Leave as [TO BE CONFIGURED] — I'll set these when I know my target hardware
  • If [A]: populate with the suggested defaults. If [B]: leave as placeholder.
• Testing: Suggest the engine-appropriate framework — gdUnit4 for Godot, NUnit for Unity, Automation Spec for Unreal — and ask before adding.

  Must match commands.test in Section 5.5.1, which writes gdUnit4's own runner (res://addons/gdUnit4/bin/GdUnitCmdTool.gd), and .claude/docs/coding-standards.md, which names the same runner. Naming GUT here would have the skill recommend one framework and configure another in the same run.

• Forbidden Patterns: Leave as placeholder — do NOT pre-populate.
• Allowed Libraries: Leave as placeholder — do NOT pre-populate dependencies the project does not currently need. Only add a library here when it is actively being integrated, not speculatively.

Guardrail: Never add speculative dependencies to Allowed Libraries. For example, do NOT add GodotSteam unless Steam integration is actively beginning in this session. Post-launch integrations should be added to Allowed Libraries when that work begins, not during engine setup.

Engine Specialists Routing

Also populate the ## Engine Specialists section in technical-preferences.md with the correct routing for the chosen engine:

For Godot — see .claude/skills/setup-engine/references/godot-language-config.md (A3) for the routing table matching the language chosen.

For Unity:

## Engine Specialists
- **Primary**: unity-specialist
- **Language/Code Specialist**: unity-specialist (C# review — primary covers it)
- **Shader Specialist**: unity-shader-specialist (Shader Graph, HLSL, URP/HDRP materials)
- **UI Specialist**: unity-ui-specialist (UI Toolkit UXML/USS, UGUI Canvas, runtime UI)
- **Additional Specialists**: unity-dots-specialist (ECS, Jobs system, Burst compiler), unity-addressables-specialist (asset loading, memory management, content catalogs)
- **Routing Notes**: Invoke primary for architecture and general C# code review. Invoke DOTS specialist for any ECS/Jobs/Burst code. Invoke shader specialist for rendering and visual effects. Invoke UI specialist for all interface implementation. Invoke Addressables specialist for asset management systems.

### File Extension Routing

| File Extension / Type | Specialist to Spawn |
|-----------------------|---------------------|
| Game code (.cs files) | unity-specialist |
| Shader / material files (.shader, .shadergraph, .mat) | unity-shader-specialist |
| UI / screen files (.uxml, .uss, Canvas prefabs) | unity-ui-specialist |
| Scene / prefab / level files (.unity, .prefab) | unity-specialist |
| Native extension / plugin files (.dll, native plugins) | unity-specialist |
| General architecture review | unity-specialist |

For Unreal:

## Engine Specialists
- **Primary**: unreal-specialist
- **Language/Code Specialist**: ue-blueprint-specialist (Blueprint graphs) or unreal-specialist (C++)
- **Shader Specialist**: unreal-specialist (no dedicated shader specialist — primary covers materials)
- **UI Specialist**: ue-umg-specialist (UMG widgets, CommonUI, input routing, widget styling)
- **Additional Specialists**: ue-gas-specialist (Gameplay Ability System, attributes, gameplay effects), ue-replication-specialist (property replication, RPCs, client prediction, netcode)
- **Routing Notes**: Invoke primary for C++ architecture and broad engine decisions. Invoke Blueprint specialist for Blueprint graph architecture and BP/C++ boundary design. Invoke GAS specialist for all ability and attribute code. Invoke replication specialist for any multiplayer or networked systems. Invoke UMG specialist for all UI implementation.

### File Extension Routing

| File Extension / Type | Specialist to Spawn |
|-----------------------|---------------------|
| Game code (.cpp, .h files) | unreal-specialist |
| Shader / material files (.usf, .ush, Material assets) | unreal-specialist |
| UI / screen files (.umg, UMG Widget Blueprints) | ue-umg-specialist |
| Scene / prefab / level files (.umap, .uasset) | unreal-specialist |
| Native extension / plugin files (Plugin .uplugin, modules) | unreal-specialist |
| Blueprint graphs (.uasset BP classes) | ue-blueprint-specialist |
| General architecture review | unreal-specialist |

Collaborative Step

Present the filled-in preferences to the user. For Godot, include the chosen language and note where the full naming conventions and routing tables live:

"Here are the default technical preferences for [engine] ([language if Godot]). The naming conventions and specialist routing are in this skill's references directory — I'll apply the [GDScript/C#/Both] variant. Want to customize any of these, or may I save them to .claude/docs/technical-preferences.md?"

For all other engines, present the defaults directly without referencing the appendix.

Wait for approval before writing the file.

5.5 Populate project.yaml (Primary Config Store)

v1.1: project.yaml at the repo root is the primary store for project configuration. The .claude/docs/technical-preferences.md file written in Section 5 is kept as a legacy mirror for backward compatibility. This step is a dual-write — the same engine facts go into both files, and project.yaml wins when a skill reads a key present in both.

After technical-preferences.md is written and approved, dual-write the structured config into project.yaml. Four blocks are written: engine, specialists, naming, and commands.

5.5.1 Build the four blocks

Derive every value from the engine and language already chosen in Sections 3–4. Do NOT re-ask for the engine, version or language — reuse those decisions.

That is not a blanket "never ask". rendering and physics below depend on two further inputs — target platform and 2D-vs-3D — which Section 2 collects on only one of the four entry paths. When they were never collected, ask; the unavailable-branch under the project-shape table says how.

engine block:

engine:
  name: "<Godot|Unity|Unreal>"
  version: "<version from Section 3>"
  language: "<GDScript|C#|C++|Blueprint>"
  rendering: "<engine default — see table>"
  physics: "<engine default — see table>"

On Godot these two values depend on the answers Section 2 already collected — the target platform and 2D-vs-3D — so do not pick them from the engine name alone. On Unity and Unreal the table has a single any row and the engine name is sufficient; take those rows directly.

Why this table has a shape column and the others do not. Both Godot defaults were wrong for a 2D browser game, and both were wrong from data this skill had already collected and then discarded.

• Jolt is Godot's default 3D engine. docs/engine-reference/godot/modules/physics.md: "Jolt Physics is the DEFAULT 3D engine" and "2D physics UNCHANGED (still Godot Physics 2D)". Writing Jolt on a 2D project sends the implementer to tune a backend their game does not use.
• Forward+ is desktop-focused. docs/engine-reference/godot/modules/rendering.md: Forward+ is "Full featured, desktop-focused"; Compatibility is "OpenGL 3.3 / WebGL 2, broadest hardware support" — the browser path.

If Section 2's platform answer was Multiple platforms including web, use the web row: the renderer must work everywhere the game ships.

Godot only — Unity and Unreal have one row each, keyed any. Shape cannot change rendering or physics for those two, so do not run the resolution below for them: asking an operator a question whose answer you will discard is exactly what §5.5.1 opens by forbidding. On Unity write URP/PhysX and on Unreal write Lumen + Nanite (deferred)/Chaos straight from the table.

Section 2 did not necessarily run — check before reading its answers. Target platform and 2D-vs-3D are collected under Questions 2–6, only if no prior engine experience. Three of the four entry paths never reach them: /setup-engine <engine> <version> and /setup-engine <engine> skip Section 2 outright, and guided mode skips the matrix as soon as the user names an engine they have worked in before. Only guided mode answered None or Multiple collects both.

Resolve each input in this order and stop at the first that answers:

1. Section 2's answers, if that path ran.
2. The design artifact — design/gdd/game-concept.md at standard/full, design/game-brief.md at minimal. Section 2 already extracts platform targets from these; extract 2D-vs-3D the same way when it is stated.
3. Ask. Do not infer the shape from the engine name, and do not write a row you could not justify:
   • Prompt: "rendering and physics depend on the project's shape, which hasn't been established yet. Is this 2D or 3D, and does it ship to web?"
   • Options: 2D · non-web / 2D · web / 3D · non-web / 3D · web, plus Leave as [TO BE CONFIGURED] — a legitimate answer here, revisited via /settings once the concept exists.

[TO BE CONFIGURED] is a valid value for both keys. A wrong Jolt on a 2D project is worse than an unset one, because nothing downstream questions it.

• rendering and physics are engine-typical defaults — tell the user they can be changed later via /settings if the project uses a different setup.
• For Godot Both, write language: "GDScript" (the primary gameplay language); the C# usage is recorded in technical-preferences.md.
• For Unreal, write language: "C++" — or "Blueprint" only if the project is Blueprint-primary. Blueprint as a secondary tool does not change this value.

specialists block — copy directly from the routing table chosen in Section 5 (A3 in .claude/skills/setup-engine/references/godot-language-config.md for Godot):

specialists:
  code: "<code specialist>"
  shader: "<shader specialist>"
  ui: "<ui specialist>"
  additional: ["<...>"]

naming block — enum values (NOT the prose form used in technical-preferences.md). Use the column matching the engine and, for Godot, the language:

The Unreal column is sourced, not inherited from the table's generic shape. variables: camelCase and signals: on_event_name are the two rows that shape would produce, and both are wrong for Unreal. Checked against this repo's pinned reference: docs/engine-reference/unreal/ contains zero camelCase variable declarations and uses PascalCase throughout (int32 Health;, FVector ServerPosition;), and the word "signal" never appears in it at all — it is Godot vocabulary. Unreal has delegates and events, and the reference's handlers are PascalCase On<Event>.

Two caveats kept rather than smoothed over. (1) classes: PascalCase is incomplete for Unreal, not wrong: UE requires a mandatory type prefix (U/A/F/E/I/T) that this enum cannot express, so an Unreal project's coding standards must state it separately. (2) scenes is a category mismatch — Unreal has Levels and Maps under World Partition, not scenes — left in place because the key is shared across engines and renaming it is a schema change, not a value fix.

The blast radius is limited: naming.* is currently a documented-but-unread setting, so wrong values misinform a human reading project.yaml rather than driving any automated check — today. That is a reason to get them right now, while it is cheap.

Three further rules for this table.

The Unity build row must not hardcode -buildTarget StandaloneLinux64. A hardcoded target gives every Unity project a Linux build command, whatever platform it actually ships on. The row reads <TARGET>: ask the operator for the build target and write the value they give. The correct -buildTarget identifiers are not sourceable from docs/engine-reference/unity/, so this skill must not emit one from recall — the same call made for /security-audit's save patterns and for Unity's release dates. A wrong-but-plausible default is worse than an explicit question: it produces a commands.build that runs, succeeds, and builds the wrong artifact.

-buildTarget alone builds nothing. It switches the active platform and exits 0 (verified on 6000.3.23f1). The row also needs a player-build flag, -build<PLATFORM>Player <output path> — for Windows 64-bit, -buildWindows64Player Builds/Win64/<Game>.exe (verified: exit 0 and an .exe; exit 1 on a compile error or when no scene is in the build settings). Ask which platform, and confirm any other platform's flag against Unity's command-line documentation rather than recalling one.

The Godot build row must not hardcode 'Linux/X11' either — same defect, same remedy. A Godot export preset name is project-defined: it is whatever string the operator typed into export_presets.cfg, and the shipped defaults are per-platform (Windows Desktop, macOS, Web, Linux/X11). Writing 'Linux/X11' gives a Windows-targeting project a build command that fails with Unknown export preset, and gives a project that does have a Linux preset a command that silently builds the wrong platform. The row reads <PRESET>: ask the operator which export preset to build and write the value they give, exactly as the Unity row does. If no presets exist yet — common, since /setup-engine usually runs before the Godot project has any — write [TO BE CONFIGURED] and say so, rather than guessing a name that does not exist.

The constants row must not contradict this skill's own prose. The table says SCREAMING_SNAKE for Unity; the Unity section of this same file says "Constants: PascalCase or UPPER_SNAKE_CASE". Both cannot be authoritative, and an agent following one produces config the other rejects. The row is left unchanged pending sourcing rather than picked by preference — neither docs/engine-reference/unity/ nor unreal/ contains a SCREAMING_SNAKE constant to confirm or refute it, and the Unreal run flagged the same row as wrong for Unreal on the same grounds. Resolve by adding a naming section to the engine references, then correct table and prose together. Until then, treat naming.constants as unverified for Unity and Unreal.

Write that caveat into project.yaml, do not leave it here. On Unity and Unreal, emit the constants line with a trailing comment:

naming:
  constants: SCREAMING_SNAKE   # UNVERIFIED — not sourceable from
                               # docs/engine-reference/<engine>/; confirm before relying on it

Without it, a value the skill knows is unsourced is recorded as flatly as classes: PascalCase, which is sourced, and the reader of the primary config store cannot tell them apart. The commands block nine lines below already does exactly this with its # TODO: confirm these line — this is the same pattern, applied to the value that needs it just as much.

For Godot Both, use the GDScript column — .gd files dominate gameplay scripting; .cs files follow C# conventions per-file (see A2 in .claude/skills/setup-engine/references/godot-language-config.md).

naming:
  classes: <value>
  variables: <value>
  constants: <value>
  signals: <value>
  files: <value>
  scenes: <value>

commands block — engine-default shell commands, simple-string form:

What each exit code proves — every row verified on the pinned engines. Godot test exits 0 when all pass, 100 on a failure, 101 when all pass but nodes leaked (a warning, not a failure), 105 when a test script does not parse, and 103 / 104 when gdUnit4 cannot run at all (headless refused, Godot older than 4.3). Keep --remote-debug tcp://127.0.0.1:0: without it a script error opens Godot's interactive debugger and the run waits at a debug> prompt forever instead of exiting. Run godot --headless --path . --import before it on a fresh clone: with no .godot/ class cache, GdUnitCmdTool.gd did not load and the run exits 1 having run nothing. Unity test exits 0 / 2, and a results file with testcasecount="0" means no test was compiled — not a pass. It runs Edit Mode only: Play Mode tests under Assets/Tests/PlayMode/ need a second run into their own results file (-testPlatform PlayMode -testResults test-results/playmode.xml), which /smoke-check makes whenever that folder holds tests and CI runs as its own step. Unity smoke exits 1 on a compile error, 0 when clean. Godot smoke exits 0 even on a parse error — it is a boot check: read its output for SCRIPT ERROR. It also needs run/main_scene set: without one it prints Can't run project: no main scene defined and never exits, so run it under a timeout. Unity smoke compiles only the editor-side assemblies; an error that exists only in a player build (an Editor/ script without its own assembly) shows up in build, not here. The real Godot parse check is godot --headless --path . --import, then godot --headless --path . -s res://.claude/scripts/godot-parse-check.gd -- res://<file>.gd … (exit 1 when a script does not load). --check-only is not one: it fails valid code that names an autoload. <Unity editor> is the editor executable's full path, quoted. Never write bare Unity: on PATH that name may be Unity's separate CLI, which rejects -batchmode with exit 2 — the same code as a failed test.

commands.run is the one the run-and-observe step depends on. It must launch the game, windowed, at a fixed resolution — never the editor, and never with a headless / batch / null-RHI flag, which exist to skip rendering. /dev-story Phase 6 step 4 appends the per-engine capture flags to it (.claude/docs/run-and-observe.md). smoke is Unity's parse check, test feeds /smoke-check; build is the one row you must ask for.

YAML quoting rule — applies to EVERY command value. yaml-helper.sh — the parser every config read in this framework goes through — decodes no escape sequences: neither \" inside a double-quoted scalar nor '' inside a single-quoted scalar. It takes the first matching quote character as the end of the value and discards the rest, so "he said \"hi\" now" parses as he said \. Verified against the parser, not inferred. The rule is load-bearing: /smoke-check and /dev-story run these values, /settings reads and writes them through this parser, and the same holds for every other quoted value in project.yaml. Pick the quote style that needs no escaping:

• value contains a single quote ' (e.g. the Godot build above) → wrap it in a double-quoted YAML scalar: "... 'Linux/X11' ..."
• value contains a double quote " (e.g. the Unreal test/smoke below) → wrap it in a single-quoted YAML scalar: '... "Quit" ...'
• value contains neither → use a double-quoted scalar for consistency. Never use a quote style that forces an escape (\" or '') — the parser truncates the value at the escape. A value containing BOTH quote types cannot be represented for this parser; rewrite the command to drop one.

Godot / Unity — write the table values directly, substituting the operator's answer for <PRESET> / <TARGET> / <PLATFORM>, and the editor's full path for <Unity editor>. Godot's build contains a single quote, so it takes a double-quoted scalar (Windows Desktop below is the example answer, not a default — write what the operator said):

commands:
  build: "godot --headless --export-debug 'Windows Desktop'"
  test: "godot --headless -s -d --remote-debug tcp://127.0.0.1:0 res://addons/gdUnit4/bin/GdUnitCmdTool.gd -a res://tests --ignoreHeadlessMode"
  run: "godot --path . --windowed --resolution 1280x720"
  smoke: "godot --headless --quit-after 5"

Write bare godot only when Section 3's godot --version ran — that is, godot is on PATH. Otherwise (the usual case on Windows and macOS) substitute the executable the probe found or the user gave — a Windows Godot_v<version>-stable_win64.exe, macOS /Applications/Godot.app/Contents/MacOS/Godot — as its full path, in double quotes, for the leading godot in all four values, exactly as <Unity editor> is. The value then holds double quotes, so it takes a single-quoted scalar, and build quotes its preset with double quotes too, so no value holds both quote types. Godot not on PATH, installed under C:/Program Files/Godot/:

commands:
  build: '"C:/Program Files/Godot/Godot_v4.6.1-stable_win64.exe" --headless --export-debug "Windows Desktop"'
  test: '"C:/Program Files/Godot/Godot_v4.6.1-stable_win64.exe" --headless -s -d --remote-debug tcp://127.0.0.1:0 res://addons/gdUnit4/bin/GdUnitCmdTool.gd -a res://tests --ignoreHeadlessMode'
  run: '"C:/Program Files/Godot/Godot_v4.6.1-stable_win64.exe" --path . --windowed --resolution 1280x720'
  smoke: '"C:/Program Files/Godot/Godot_v4.6.1-stable_win64.exe" --headless --quit-after 5'

If the probe found no executable and the user does not know where it is, keep bare godot, put # TODO: godot is not on PATH here — set the editor's full path via /settings above the block, and say so: those commands will not run until one of the two is fixed.

For Unity, probe the Hub install (C:/Program Files/Unity/Hub/Editor/<version>/Editor/Unity.exe on Windows, /Applications/Unity/Hub/Editor/<version>/Unity.app/Contents/MacOS/Unity on macOS, /home/<user>/Unity/Hub/Editor/<version>/Editor/Unity on Linux) or ask. Write the expanded absolute path — a ~ inside quotes is not expanded, and the command then exits 127. The quoted path puts double quotes in the command, so the value takes a single-quoted scalar:

commands:
  test: '"C:/Program Files/Unity/Hub/Editor/6000.3.23f1/Editor/Unity.exe" -batchmode -runTests -projectPath . -testPlatform EditMode -testResults test-results/editmode.xml'
  smoke: '"C:/Program Files/Unity/Hub/Editor/6000.3.23f1/Editor/Unity.exe" -batchmode -quit -projectPath . -logFile -'

Also write engine.path if the editor is not on PATH. Agents and /smoke-check read it to find the editor, but a command is run as written — engine.path is never spliced into commands.* at run time, which is why the full path goes into the commands above — and on Windows and macOS none of the three engines installs onto PATH by default (on macOS the editor is inside an app bundle, e.g. /Applications/Godot.app/Contents/MacOS/Godot). Ask for or probe the install location and record it — the editor executable for Godot and Unity, the engine folder (<UE root>) for Unreal:

engine:
  path: "C:/Program Files/Epic Games/UE_5.7"   # omit if the editor is on PATH

This is not cosmetic. Without it, an agent reports "no editor on this machine" and ships C++ it never compiled — on a machine where that engine WAS installed. Nothing in the project told it where to look, so absence of a path read as absence of an engine.

For Unreal, UE build/test commands vary by version and project setup. Write best-effort values and add a # TODO comment so the user knows to confirm them. Substitute the engine's install folder for <UE root> (the value you record as engine.path) — none of the editor binaries is on PATH. The commands embed double quotes, so they take single-quoted scalars. Write the block for the machine the project is developed on (uname -s: Linux, Darwin = macOS, anything else = Windows). The Windows block was run on UE 5.7; the Linux and macOS lines come from Epic's documentation, recorded with their sources in docs/engine-reference/unreal/current-best-practices.md ("Command Line").

Windows:

commands:
  # TODO: confirm these for your UE version and project — adjust via /settings
  build: '"<UE root>/Engine/Binaries/DotNET/AutomationTool/AutomationTool.exe" BuildCookRun -project="$(pwd -W 2>/dev/null || pwd)/<project>.uproject" -platform=Win64 -build -cook'
  test: '"<UE root>/Engine/Binaries/Win64/UnrealEditor-Cmd.exe" "$(pwd -W 2>/dev/null || pwd)/<project>.uproject" -ExecCmds="Automation RunTests <project>.; Quit" -unattended -nullrhi -stdout -FullStdOutLogOutput'
  run: '"<UE root>/Engine/Binaries/Win64/UnrealEditor.exe" "$(pwd -W 2>/dev/null || pwd)/<project>.uproject" -game -windowed -ResX=1280 -ResY=720'
  smoke: '"<UE root>/Engine/Binaries/Win64/UnrealEditor-Cmd.exe" "$(pwd -W 2>/dev/null || pwd)/<project>.uproject" -game -nullrhi -unattended -stdout -ExecCmds="Quit"'

Linux — the editor binary is Engine/Binaries/Linux/UnrealEditor, the build scripts are shell scripts:

commands:
  # TODO: confirm these for your UE version and project — adjust via /settings
  build: '"<UE root>/Engine/Build/BatchFiles/RunUAT.sh" BuildCookRun -project="$(pwd -W 2>/dev/null || pwd)/<project>.uproject" -platform=Linux -build -cook'
  test: '"<UE root>/Engine/Binaries/Linux/UnrealEditor" "$(pwd -W 2>/dev/null || pwd)/<project>.uproject" -ExecCmds="Automation RunTests <project>.; Quit" -unattended -nullrhi -stdout -FullStdOutLogOutput'
  run: '"<UE root>/Engine/Binaries/Linux/UnrealEditor" "$(pwd -W 2>/dev/null || pwd)/<project>.uproject" -game -windowed -ResX=1280 -ResY=720'
  smoke: '"<UE root>/Engine/Binaries/Linux/UnrealEditor" "$(pwd -W 2>/dev/null || pwd)/<project>.uproject" -game -nullrhi -unattended -stdout -ExecCmds="Quit"'

macOS — only the build is sourced. Epic documents the UnrealEditor.app bundle but no command-line editor inside it, so write build and leave the other three as TODO lines rather than a guessed path; /smoke-check reports NOT ASSESSED for tests until the user sets commands.test:

commands:
  # TODO: confirm this for your UE version and project — adjust via /settings
  build: '"<UE root>/Engine/Build/BatchFiles/RunUAT.sh" BuildCookRun -project="$(pwd -W 2>/dev/null || pwd)/<project>.uproject" -platform=Mac -build -cook'
  # TODO: test, run and smoke — no documented command-line editor on macOS.
  # Set them via /settings to the editor command you run for this project.

On Windows, build calls AutomationTool directly: from Git Bash, RunUAT.bat fails ('C:\Program' is not recognized) whenever the project path has a space. AutomationTool.exe runs on the machine's .NET 8 runtime; RunUAT.bat brings its own SDK, so with no space in the path and no .NET 8 installed, use it. -build builds the editor target too (verified on 5.7).

Three details are load-bearing. The project path is absolute: UE 5.7 does not find a relative <project>.uproject and exits 1 (Project file not found) before anything runs. $(pwd -W 2>/dev/null || pwd) gives the C:/… form in Git Bash and the plain path elsewhere, run from the project root; $PWD alone fails when MSYS_NO_PATHCONV is set. smoke needs -game: without it UnrealEditor-Cmd boots the editor, where a bare Quit console command only ends a play-in-editor session — the process stays resident and the command never returns; with -game the same line boots headless and exits in seconds. test needs the ; Quit inside the Automation string: the automation runner handles that trailing Quit itself and exits the editor once the tests finish, and without it the run also never returns. Its filter runs every test whose full name contains <project>. — a substring match, not a prefix — so name tests <project>.[System].[Scenario] as qa-tester does. If the project's name is also an engine area — Audio, Core, Input, Test, System, Engine, Editor, AI, Math — <project>. also runs hundreds to thousands of the engine's own tests; give the tests a distinct root (say <project>Game.) and put the same root in the filter. This form exits 255 on a failing test AND on a filter that matches nothing (No automation tests matched, verified on 5.7), so /smoke-check reads the output, not the exit code. smoke carries -stdout for the same reason: without it a failed boot prints nothing. Do not swap in -TestExit="Automation Test Queue Empty": that form exits 0 on a failing test unless its report JSON is parsed.