Claude-Code-Game-Studios/.claude/skills/setup-engine/SKILL.md

name, description, argument-hint, user-invocable, allowed-tools

name	description	argument-hint	user-invocable	allowed-tools
setup-engine	Configure the project's game engine and version. Pins the engine in CLAUDE.md, detects knowledge gaps, and populates engine reference docs via WebSearch when the version is beyond the LLM's training data.	[engine] | [engine version] | refresh | upgrade [old-version] [new-version] | no args for guided selection	true	Read, Glob, Grep, Write, Edit, WebSearch, WebFetch, Task

When this skill is invoked:

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 design/gdd/game-concept.md if it exists — extract genre, scope, platform targets, art style, team size, and any engine recommendation from /brainstorm
• If no concept 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."

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

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

Produce a recommendation

Use this decision matrix:

Factor	Godot 4	Unity	Unreal Engine 5
Best for	2D games, small 3D, solo/small teams	Mobile, mid-scope 3D, cross-platform	AAA 3D, photorealism, large teams
Language	GDScript (+ C#, C++ via extensions)	C#	C++ / Blueprint
Cost	Free, MIT license	Free under revenue threshold	Free under revenue threshold, 5% royalty
Learning curve	Gentle	Moderate	Steep
2D support	Excellent (native)	Good (but 3D-first engine)	Possible but not ideal
3D quality ceiling	Good (improving rapidly)	Very good	Best-in-class
Web export	Yes (native)	Yes (limited)	No
Console export	Via third-party	Yes (with license)	Yes
Open source	Yes	No	Source available

Present the top 1-2 recommendations with reasoning tied to the user's answers. Let the user choose — never force a recommendation.

---

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?"

---

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.

---

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 Appendix A at the bottom of this skill 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)
- **Build System**: Unreal Build Tool (UBT)
- **Asset Pipeline**: Unreal Content Pipeline

---

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 Appendix A 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:

Platform target	Gamepad Support	Touch Support
PC only	Partial (recommended)	None
Console	Full	None
Mobile	None	Full
PC + Console	Full	None
PC + Mobile	Partial	Full
Web	Partial	Partial

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

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: Leave as [TO BE CONFIGURED] with a suggestion:

  "Typical targets: 60fps / 16.6ms frame budget. Want to set these now?"

• Testing: Suggest engine-appropriate framework (GUT for Godot, NUnit for Unity, etc.)
• Forbidden Patterns / Allowed Libraries: Leave as placeholder

Engine Specialists Routing

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

For Godot — see Appendix A 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 Appendix A of this skill — I'll apply the [GDScript/C#/Both] variant. Want to customize any of these, or shall I save the defaults?"

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

Wait for approval before writing the file.

---

6. Determine Knowledge Gap

Check whether the engine version is likely beyond the LLM's training data.

Known approximate coverage (update this as models change):

• LLM knowledge cutoff: May 2025
• Godot: training data likely covers up to ~4.3
• Unity: training data likely covers up to ~2023.x / early 6000.x
• Unreal: training data likely covers up to ~5.3 / early 5.4

Compare the user's chosen version against these baselines:

• Within training data → LOW RISK — reference docs optional but recommended
• Near the edge → MEDIUM RISK — reference docs recommended
• Beyond training data → HIGH RISK — reference docs required

Inform the user which category they're in and why.

---

7. Populate Engine Reference Docs

If WITHIN training data (LOW RISK):

Create a minimal docs/engine-reference/<engine>/VERSION.md:

# [Engine] — Version Reference

| Field | Value |
|-------|-------|
| **Engine Version** | [version] |
| **Project Pinned** | [today's date] |
| **LLM Knowledge Cutoff** | May 2025 |
| **Risk Level** | LOW — version is within LLM training data |

## Note

This engine version is within the LLM's training data. Engine reference
docs are optional but can be added later if agents suggest incorrect APIs.

Run `/setup-engine refresh` to populate full reference docs at any time.

Do NOT create breaking-changes.md, deprecated-apis.md, etc. — they would add context cost with minimal value.

If BEYOND training data (MEDIUM or HIGH RISK):

Create the full reference doc set by searching the web:

1. Search for the official migration/upgrade guide:

   • "[engine] [old version] to [new version] migration guide"
   • "[engine] [version] breaking changes"
   • "[engine] [version] changelog"
   • "[engine] [version] deprecated API"

2. Fetch and extract from official documentation:

   • Breaking changes between each version from the training cutoff to current
   • Deprecated APIs with replacements
   • New features and best practices

Ask: "May I create the engine reference docs under docs/engine-reference/<engine>/?"

Wait for confirmation before writing any files.

3. Create the full reference directory:

   docs/engine-reference/<engine>/
   ├── VERSION.md              # Version pin + knowledge gap analysis
   ├── breaking-changes.md     # Version-by-version breaking changes
   ├── deprecated-apis.md      # "Don't use X → Use Y" tables
   ├── current-best-practices.md  # New practices since training cutoff
   └── modules/                # Per-subsystem references (create as needed)
   

4. Populate each file using real data from the web searches, following the format established in existing reference docs. Every file must have a "Last verified: [date]" header.

5. For module files: Only create modules for subsystems where significant changes occurred. Don't create empty or minimal module files.

---

8. Update CLAUDE.md Import

Ask: "May I update the @ import in CLAUDE.md to point to the new engine reference?"

Wait for confirmation, then update the @ import under "Engine Version Reference" to point to the correct engine:

## Engine Version Reference

@docs/engine-reference/<engine>/VERSION.md

If the previous import pointed to a different engine (e.g., switching from Godot to Unity), update it.

---

9. Update Agent Instructions

Ask: "May I add a Version Awareness section to the engine specialist agent files?" before making any edits.

For the chosen engine's specialist agents, verify they have a "Version Awareness" section. If not, add one following the pattern in the existing Godot specialist agents.

The section should instruct the agent to:

1. Read docs/engine-reference/<engine>/VERSION.md
2. Check deprecated APIs before suggesting code
3. Check breaking changes for relevant version transitions
4. Use WebSearch to verify uncertain APIs

---

10. Refresh Subcommand

If invoked as /setup-engine refresh:

1. Read the existing docs/engine-reference/<engine>/VERSION.md to get the current engine and version
2. Use WebSearch to check for:
   • New engine releases since last verification
   • Updated migration guides
   • Newly deprecated APIs
3. Update all reference docs with new findings
4. Update "Last verified" dates on all modified files
5. Report what changed

---

11. Upgrade Subcommand

If invoked as /setup-engine upgrade [old-version] [new-version]:

Step 1 — Read Current Version State

Read docs/engine-reference/<engine>/VERSION.md to confirm the current pinned version, risk level, and any migration note URLs already recorded. If old-version was not provided as an argument, use the pinned version from this file.

Step 2 — Fetch Migration Guide

Use WebSearch and WebFetch to locate the official migration guide between old-version and new-version:

• Search: "[engine] [old-version] to [new-version] migration guide"
• Search: "[engine] [new-version] breaking changes changelog"
• Fetch the migration guide URL from VERSION.md if one is already recorded, or use the URL found via search.

Extract: renamed APIs, removed APIs, changed defaults, behavior changes, and any "must migrate" items.

Step 3 — Pre-Upgrade Audit

Scan src/ for code that uses APIs known to be deprecated or changed in the target version:

• Use Grep to search for deprecated API names extracted from the migration guide (e.g., old function names, removed node types, changed property names)
• List each file that matches, with the specific API reference found

Present the audit results as a table:

Pre-Upgrade Audit: [engine] [old-version] → [new-version]
==========================================================

Files requiring changes:
  File                              | Deprecated API Found       | Effort
  --------------------------------- | -------------------------- | ------
  src/gameplay/player_movement.gd   | old_api_name               | Low
  src/ui/hud.gd                     | removed_node_type          | Medium

Breaking changes to watch for:
  - [change description from migration guide]
  - [change description from migration guide]

Recommended migration order (dependency-sorted):
  1. [system/layer with fewest dependencies first]
  2. [next system]
  ...

If no deprecated APIs are found in src/, report: "No deprecated API usage found in src/ — upgrade may be low-risk."

Step 4 — Confirm Before Updating

Ask the user before making any changes:

"Pre-upgrade audit complete. Found [N] files using deprecated APIs. Proceed with upgrading VERSION.md to [new-version]? (This will update the pinned version and add migration notes — it does NOT change any source files. Source migration is done manually or via stories.)"

Wait for explicit confirmation before continuing.

Step 5 — Update VERSION.md

After confirmation:

1. Update docs/engine-reference/<engine>/VERSION.md:

   • Engine Version → [new-version]
   • Project Pinned → today's date
   • Last Docs Verified → today's date
   • Re-evaluate and update the Risk Level and Post-Cutoff Version Timeline table if the new version falls beyond the LLM knowledge cutoff
   • Add a ## Migration Notes — [old-version] → [new-version] section containing: migration guide URL, key breaking changes, deprecated APIs found in this project, and recommended migration order from the audit

2. If breaking-changes.md or deprecated-apis.md exist in the engine reference directory, append the new version's changes to those files.

Step 6 — Post-Upgrade Reminder

After updating VERSION.md, output:

VERSION.md updated: [engine] [old-version] → [new-version]

Next steps:
1. Migrate deprecated API usages in the [N] files listed above
2. Run /setup-engine refresh after upgrading the actual engine binary to
   verify no new deprecations were missed
3. Run /architecture-review — the engine upgrade may invalidate ADRs that
   reference specific APIs or engine capabilities
4. If any ADRs are invalidated, run /propagate-design-change to update
   downstream stories

---

12. Output Summary

After setup is complete, output:

Engine Setup Complete
=====================
Engine:          [name] [version]
Language:        [GDScript | C# | GDScript + C# | C# | C++ + Blueprint]
Knowledge Risk:  [LOW/MEDIUM/HIGH]
Reference Docs:  [created/skipped]
CLAUDE.md:       [updated]
Tech Prefs:      [created/updated]
Agent Config:    [verified]

Next Steps:
1. Review docs/engine-reference/<engine>/VERSION.md
2. [If from /brainstorm] Run /map-systems to decompose your concept into individual systems
3. [If from /brainstorm] Run /design-system to author per-system GDDs (guided, section-by-section)
4. [If from /brainstorm] Run /prototype [core-mechanic] to test the core loop
5. [If fresh start] Run /brainstorm to discover your game concept
6. Create your first milestone: /sprint-plan new

---

Verdict: COMPLETE — engine configured and reference docs populated.

Guardrails

• NEVER guess an engine version — always verify via WebSearch or user confirmation
• NEVER overwrite existing reference docs without asking — append or update
• If reference docs already exist for a different engine, ask before replacing
• Always show the user what you're about to change before making CLAUDE.md edits
• If WebSearch returns ambiguous results, show the user and let them decide

---

Appendix A — Godot Language Configuration

All Godot-specific variants for language-dependent configuration. Referenced from Sections 4 and 5 — only relevant when Godot is the chosen engine. Use the subsection matching the language chosen in Section 4.

---

A1. CLAUDE.md Technology Stack Templates

GDScript:

- **Engine**: Godot [version]
- **Language**: GDScript (primary), C++ via GDExtension (performance-critical)
- **Build System**: SCons (engine), Godot Export Templates
- **Asset Pipeline**: Godot Import System + custom resource pipeline

C#:

- **Engine**: Godot [version]
- **Language**: C# (.NET 8+, primary), C++ via GDExtension (native plugins only)
- **Build System**: .NET SDK + Godot Export Templates
- **Asset Pipeline**: Godot Import System + custom resource pipeline

Both — GDScript + C#:

- **Engine**: Godot [version]
- **Language**: GDScript (gameplay/UI scripting), C# (performance-critical systems), C++ via GDExtension (native only)
- **Build System**: .NET SDK + Godot Export Templates
- **Asset Pipeline**: Godot Import System + custom resource pipeline

---

A2. Naming Conventions

GDScript:

• Classes: PascalCase (e.g., PlayerController)
• Variables/functions: snake_case (e.g., move_speed)
• Signals: snake_case past tense (e.g., health_changed)
• Files: snake_case matching class (e.g., player_controller.gd)
• Scenes: PascalCase matching root node (e.g., PlayerController.tscn)
• Constants: UPPER_SNAKE_CASE (e.g., MAX_HEALTH)

C#:

• Classes: PascalCase (PlayerController) — must also be partial
• Public properties/fields: PascalCase (MoveSpeed, JumpVelocity)
• Private fields: _camelCase (_currentHealth, _isGrounded)
• Methods: PascalCase (TakeDamage(), GetCurrentHealth())
• Signal delegates: PascalCase + EventHandler suffix (HealthChangedEventHandler)
• Files: PascalCase matching class (PlayerController.cs)
• Scenes: PascalCase matching root node (PlayerController.tscn)
• Constants: PascalCase (MaxHealth, DefaultMoveSpeed)

Both — GDScript + C#: Use GDScript conventions for .gd files and C# conventions for .cs files. Mixed-language files do not exist — the boundary is per-file. When in doubt about which language a new system should use, ask the user and record the decision in technical-preferences.md.

---

A3. Engine Specialists Routing

GDScript:

## Engine Specialists
- **Primary**: godot-specialist
- **Language/Code Specialist**: godot-gdscript-specialist (all .gd files)
- **Shader Specialist**: godot-shader-specialist (.gdshader files, VisualShader resources)
- **UI Specialist**: godot-specialist (no dedicated UI specialist — primary covers all UI)
- **Additional Specialists**: godot-gdextension-specialist (GDExtension / native C++ bindings only)
- **Routing Notes**: Invoke primary for architecture decisions, ADR validation, and cross-cutting code review. Invoke GDScript specialist for code quality, signal architecture, static typing enforcement, and GDScript idioms. Invoke shader specialist for material design and shader code. Invoke GDExtension specialist only when native extensions are involved.

### File Extension Routing

| File Extension / Type | Specialist to Spawn |
|-----------------------|---------------------|
| Game code (.gd files) | godot-gdscript-specialist |
| Shader / material files (.gdshader, VisualShader) | godot-shader-specialist |
| UI / screen files (Control nodes, CanvasLayer) | godot-specialist |
| Scene / prefab / level files (.tscn, .tres) | godot-specialist |
| Native extension / plugin files (.gdextension, C++) | godot-gdextension-specialist |
| General architecture review | godot-specialist |

C#:

## Engine Specialists
- **Primary**: godot-specialist
- **Language/Code Specialist**: godot-csharp-specialist (all .cs files)
- **Shader Specialist**: godot-shader-specialist (.gdshader files, VisualShader resources)
- **UI Specialist**: godot-specialist (no dedicated UI specialist — primary covers all UI)
- **Additional Specialists**: godot-gdextension-specialist (GDExtension / native C++ bindings only)
- **Routing Notes**: Invoke primary for architecture decisions, ADR validation, and cross-cutting code review. Invoke C# specialist for code quality, [Signal] delegate patterns, [Export] attributes, .csproj management, and C#-specific Godot idioms. Invoke shader specialist for material design and shader code. Invoke GDExtension specialist only when native C++ plugins are involved.

### File Extension Routing

| File Extension / Type | Specialist to Spawn |
|-----------------------|---------------------|
| Game code (.cs files) | godot-csharp-specialist |
| Shader / material files (.gdshader, VisualShader) | godot-shader-specialist |
| UI / screen files (Control nodes, CanvasLayer) | godot-specialist |
| Scene / prefab / level files (.tscn, .tres) | godot-specialist |
| Project config (.csproj, NuGet) | godot-csharp-specialist |
| Native extension / plugin files (.gdextension, C++) | godot-gdextension-specialist |
| General architecture review | godot-specialist |

Both — GDScript + C#:

## Engine Specialists
- **Primary**: godot-specialist
- **GDScript Specialist**: godot-gdscript-specialist (.gd files — gameplay/UI scripts)
- **C# Specialist**: godot-csharp-specialist (.cs files — performance-critical systems)
- **Shader Specialist**: godot-shader-specialist (.gdshader files, VisualShader resources)
- **UI Specialist**: godot-specialist (no dedicated UI specialist — primary covers all UI)
- **Additional Specialists**: godot-gdextension-specialist (GDExtension / native C++ bindings only)
- **Routing Notes**: Invoke primary for cross-language architecture decisions and which systems belong in which language. Invoke GDScript specialist for .gd files. Invoke C# specialist for .cs files and .csproj management. Prefer signals over direct cross-language method calls at the boundary.

### File Extension Routing

| File Extension / Type | Specialist to Spawn |
|-----------------------|---------------------|
| Game code (.gd files) | godot-gdscript-specialist |
| Game code (.cs files) | godot-csharp-specialist |
| Cross-language boundary decisions | godot-specialist |
| Shader / material files (.gdshader, VisualShader) | godot-shader-specialist |
| UI / screen files (Control nodes, CanvasLayer) | godot-specialist |
| Scene / prefab / level files (.tscn, .tres) | godot-specialist |
| Project config (.csproj, NuGet) | godot-csharp-specialist |
| Native extension / plugin files (.gdextension, C++) | godot-gdextension-specialist |
| General architecture review | godot-specialist |