setup-engine

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

When this skill is invoked:

调用此Skill时：

1. Parse Arguments

1. 解析参数

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)

四种模式：

完整规格：
```
/setup-engine godot 4.6
```
—— 提供引擎及版本
仅引擎：
```
/setup-engine unity
```
—— 提供引擎，版本将自动查询
无参数：
```
/setup-engine
```
—— 全引导模式（引擎推荐 + 版本选择）
刷新：
```
/setup-engine refresh
```
—— 更新参考文档（见第10节）
升级：
```
/setup-engine upgrade [旧版本] [新版本]
```
—— 迁移至新引擎版本（见第11节）

2. Guided Mode (No Arguments)

2. 引导模式（无参数）

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

若存在
```
design/gdd/game-concept.md
```
则读取该文件 —— 提取游戏类型、规模、平台目标、美术风格、团队规模，以及
```
/brainstorm
```
生成的引擎推荐
若不存在游戏概念，告知用户：
"未找到游戏概念。建议先运行
```
/brainstorm
```
来明确你想要开发的内容——该工具也会推荐合适的引擎。或者告诉我你的游戏需求，我来帮你挑选引擎。"

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

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

问题1 —— 过往经验（始终优先通过

AskUserQuestion

提问）：

提示："你之前使用过以下任意引擎吗？"

选项：

Godot

Unity

Unreal Engine 5

多个——我会说明

都没有

若用户选择特定引擎 → 推荐该引擎。过往经验优先级高于所有其他因素。与用户确认后跳过决策矩阵。
若选择"都没有"或"多个" → 继续以下问题。

问题2-6 —— 决策矩阵输入（仅当用户无引擎使用经验时提问）：

问题2 —— 目标平台（始终第二个通过

AskUserQuestion

提问——平台因素会直接排除或大幅影响引擎优先级）：

提示："你的游戏目标平台是什么？"

选项：

PC（Steam / Epic）

移动端（iOS / Android）

主机

网页/浏览器

多平台

平台规则直接影响推荐结果：
- 移动端 → 优先推荐Unity；Unreal适配性差；Godot适用于简单移动端项目
- 主机 → Unity或Unreal；Godot的主机支持需要第三方发行商或大量额外工作
- 网页 → Godot可完美导出至网页；Unity WebGL可用；Unreal网页支持差
- 仅PC → 所有引擎均适用；由其他因素决定
- 多平台 → Unity是跨PC/移动端/主机最具可移植性的引擎

游戏类型？（2D、3D或两者兼顾？）
主要输入方式？（键盘/鼠标、手柄、触摸或混合输入？）
团队规模与经验？（单人新手、单人资深开发者、小型团队？）
语言偏好？（GDScript、C#、C++、可视化脚本？）
引擎授权预算？（仅免费，或可接受商业授权？）

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:

Show a comparison table with the user's specific factors as rows
Give a primary recommendation with honest reasoning
Name the best alternative and when to choose it instead
Explicitly state: "This is a starting point, not a verdict — you can always migrate engines, and many developers switch between projects."
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.

请勿使用简单评分矩阵直接排除引擎。应结合用户情况，基于以下真实权衡逻辑进行分析，然后给出1-2个带完整背景的推荐。始终由用户最终选择——绝不强制决策。

引擎真实权衡：

Godot 4

核心优势：2D领域（业内顶尖）、风格化/独立3D、快速迭代、永久免费（MIT协议）、开源、学习曲线最平缓、适合想要完全掌控的独立开发者
实际局限：3D生态相较于Unity/Unreal薄弱（3D特定问题的教程、资源、社区解答更少）；大型开放世界3D开发难度极高，且Godot尚未经过生产验证；主机导出需要第三方发行商或大量额外工作；专业就业市场较小
授权情况：真正免费，无任何营收门槛。MIT协议意味着你拥有所有成果的所有权。
最佳适配：任何规模的2D游戏；风格化/氛围型3D游戏；封闭型3D世界（非开放世界）；重视学习曲线的首次游戏项目；任何规模下预算受限的项目

Unity

核心优势：中规模3D和移动端的行业标准；庞大的资源商店和教程生态；C#是专业编程语言；独立开发者的主机认证支持最佳；几乎所有游戏类型都有强大社区
实际局限：2023年的授权争议损害了用户信任（曾提议运行时费用后撤回——政策变更风险仍存在）；C#初始学习曲线比GDScript更陡；对于简单项目而言编辑器过于繁重
授权情况：营收低于20万美元且安装量低于20万时免费（Unity Personal/Plus版）。仅当游戏真正成功时才会产生费用——大多数独立游戏永远达不到该门槛。2023年的争议值得了解，但当前实际条款对大多数独立开发者而言是合理的。
最佳适配：移动端游戏；中规模3D游戏；目标主机平台的游戏；有C#背景的开发者；需要大量资源商店的项目；2-5人团队

Unreal Engine 5

核心优势：业内顶尖的3D视觉效果（Lumen、Nanite、Chaos物理系统）；AAA级和写实3D的行业标准；大型开放世界支持成熟且经过生产验证；Blueprint可视化脚本降低了C++门槛；适合面向高端PC或主机的游戏
实际局限：学习曲线最陡峭；编辑器最繁重（编译时间慢、项目体积大）；对于风格化/2D/小型游戏而言过于冗余；C++难度高；不适用于移动端或网页；营收超过100万美元后需支付5%的版税
授权情况：仅在单款游戏总营收超过100万美元后才需支付5%版税。对于首款游戏或未达到100万美元营收的游戏，完全免费。该门槛足够高，大多数独立开发者永远无需支付。
最佳适配：AAA级质量3D游戏；大型开放世界游戏；写实视觉效果；有C++经验或愿意使用Blueprint的开发者；视觉保真度为核心卖点的高端PC/主机游戏

游戏类型特定指导（纳入推荐考量）：

任意风格2D → 优先推荐Godot
3D风格化/氛围型/封闭世界 → Godot可行，Unity是可靠替代方案
3D开放世界（大型、无缝） → Unity或Unreal；Godot尚未经过生产验证
3D写实/AAA级质量 → Unreal
移动端优先 → 优先推荐Unity
主机优先 → Unity或Unreal；Godot的主机支持需要额外工作
恐怖/叙事/步行模拟 → 任意引擎；匹配美术风格和团队经验
动作RPG/Soulslike → 3D推荐Unity或Unreal；社区支持和资源很重要
2D平台跳跃 → Godot
策略/俯视/RTS → 根据2D或3D选择Godot或Unity

推荐格式：

展示以用户特定因素为行的对比表格
给出主推荐及真实理由
列出最佳替代方案及适用场景
明确说明："这只是起点，而非最终结论——你随时可以迁移引擎，许多开发者会在不同项目间切换引擎。"

使用

AskUserQuestion

确认："这个推荐符合你的预期吗？还是你想探索其他引擎？"

选项：

[主推荐引擎]（推荐）

[替代引擎]

[第三引擎]

深入探索

输入自定义内容

若用户选择"深入探索"： 使用

AskUserQuestion

提供基于用户实际概念的深度探索主题。必须从用户实际概念生成选项，不得使用通用选项。至少包含：

主推荐引擎针对该概念的特定局限（例如："Godot 3D在[游戏类型]中的实际上限是什么？"）
替代引擎针对该概念的特定权衡
语言选择对该概念技术挑战的影响
概念特定的技术关注点（例如：自适应音频、开放世界流加载、多人网络代码）

用户可选择多个主题。深入回答每个选中主题后，再返回引擎确认问题。

3. Look Up Current Version

3. 查询当前版本

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

一旦选定引擎：

若已提供版本，直接使用
若未提供版本，通过WebSearch查找最新稳定版本：
- 搜索关键词：
```
"[engine] latest stable version [current year]"
```
- 与用户确认："[engine]的最新稳定版本是[version]。是否使用该版本？"

4. Update CLAUDE.md Technology Stack

4. 更新CLAUDE.md技术栈

Language Selection (Godot only)

语言选择（仅Godot）

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:

markdown

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

For Unreal:

markdown

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

若选择Godot，在展示拟议技术栈前先询问用户使用哪种语言：

"Godot支持两种主要语言：

A) GDScript —— 类Python语法，Godot原生语言，迭代速度最快。适合初学者、独立开发者以及有Python或Lua背景的团队。 B) C# —— .NET 8+，Unity开发者熟悉，IDE工具更强大（Rider / Visual Studio），在复杂逻辑上有轻微性能优势。 C) 两者兼顾 —— GDScript用于游戏玩法/UI脚本，C#用于性能关键系统。高级配置——需在Godot之外安装.NET SDK。

本项目将主要使用哪种语言？"

记录用户选择。该选择将决定CLAUDE.md模板、命名规范、专家路由，以及项目中代码文件对应的Agent。

读取CLAUDE.md并向用户展示拟议的技术栈变更。询问："我可以将这些引擎设置写入CLAUDE.md吗？"

在进行任何编辑前等待用户确认。

更新技术栈部分，将

[CHOOSE]

占位符替换为实际值：

Godot —— 使用与所选语言匹配的模板。见本Skill末尾的附录A，包含三种变体（GDScript、C#、两者兼顾）。

Unity：

markdown

- **引擎**: Unity [version]
- **语言**: C#
- **构建系统**: Unity Build Pipeline
- **资源管线**: Unity Asset Import Pipeline + Addressables

Unreal：

markdown

- **引擎**: Unreal Engine [version]
- **语言**: C++（主要），Blueprint（游戏玩法原型）
- **构建系统**: Unreal Build Tool (UBT)
- **资源管线**: Unreal Content Pipeline

5. Populate Technical Preferences

5. 填充技术偏好

After updating CLAUDE.md, create or update

.claude/docs/technical-preferences.md

with engine-appropriate defaults. Read the existing template first, then fill in:

更新CLAUDE.md后，创建或更新

.claude/docs/technical-preferences.md

，填入引擎对应的默认值。先读取现有模板，再填充：

Engine & Language Section

引擎与语言部分

Fill from the engine choice made in step 4

从步骤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
```
)

Godot —— 见附录A中的GDScript、C#和两者兼顾变体。

Unity（C#）：

类：PascalCase（例如：
```
PlayerController
```
）
公共字段/属性：PascalCase（例如：
```
MoveSpeed
```
）
私有字段：_camelCase（例如：
```
_moveSpeed
```
）
方法：PascalCase（例如：
```
TakeDamage()
```
）
文件：与类名匹配的PascalCase（例如：
```
PlayerController.cs
```
）
常量：PascalCase或UPPER_SNAKE_CASE

Unreal（C++）：

类：带前缀的PascalCase（
```
A
```
表示Actor，
```
U
```
表示UObject，
```
F
```
表示结构体）
变量：PascalCase（例如：
```
MoveSpeed
```
）
函数：PascalCase（例如：
```
TakeDamage()
```
）
布尔值：
```
b
```
前缀（例如：
```
bIsAlive
```
）
文件：与类名匹配（不含前缀，例如：
```
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:

markdown

undefined

使用第2节收集的答案（或从游戏概念中提取的信息）填充

## Input & Platform

部分。使用以下映射推导值：

目标平台	手柄支持	触摸支持
仅PC	部分支持（推荐）	无
主机	完全支持	无
移动端	无	完全支持
PC + 主机	完全支持	无
PC + 移动端	部分支持	完全支持
网页	部分支持	部分支持

主要输入方式使用游戏类型的主导输入：

面向主机的动作/RPG/平台跳跃游戏 → 手柄
策略/点击/RTS → 键盘/鼠标
移动端游戏 → 触摸
跨平台 → 询问用户

展示推导值并询问用户确认或调整后再写入。

示例填充部分：

markdown

undefined

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.

undefined

目标平台: PC, 主机
输入方式: 键盘/鼠标, 手柄
主要输入: 手柄
手柄支持: 完全支持
触摸支持: 无
平台说明: 所有UI必须支持方向键导航。不得仅支持悬停交互。

undefined

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 engine-appropriate framework (GUT for Godot, NUnit for Unity, etc.) — ask before adding.
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.

性能预算: 使用
```
AskUserQuestion
```
询问：
- 提示："我现在设置默认性能预算，还是留到以后？"
- 选项：
```
[A] 现在设置默认值（60fps，16.6ms帧预算，引擎适配的绘制调用限制）
```
  /
```
[B] 保留为[待配置]——我会在明确目标硬件后设置
```
- 若选[A]：填入建议的默认值。若选[B]：保留占位符。
测试: 建议引擎适配的框架（Godot用GUT，Unity用NUnit等）——添加前需询问用户。
禁用模式: 保留占位符——请勿预先填充。
允许的库: 保留占位符——请勿预先填充项目当前不需要的依赖项。仅在主动集成库时添加，不得推测性添加。

防护规则: 不得向允许的库中添加推测性依赖项。例如，除非当前会话中开始集成Steam，否则请勿添加GodotSteam。后期集成应在开始工作时添加到允许的库中，而非引擎设置阶段。

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:

markdown

undefined

同时在

technical-preferences.md

的

## Engine Specialists

部分填入所选引擎的正确路由：

Godot —— 见附录A中与所选语言匹配的路由表。

Unity：

markdown

undefined

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.

主专家: unity-specialist
语言/代码专家: unity-specialist（C#审核——主专家覆盖）
着色器专家: unity-shader-specialist（Shader Graph、HLSL、URP/HDRP材质）
UI专家: unity-ui-specialist（UI Toolkit UXML/USS、UGUI Canvas、运行时UI）
额外专家: unity-dots-specialist（ECS、Jobs系统、Burst编译器），unity-addressables-specialist（资源加载、内存管理、内容目录）
路由说明: 架构和通用C#代码审核调用主专家。任何ECS/Jobs/Burst代码调用DOTS专家。渲染和视觉效果调用着色器专家。所有界面实现调用UI专家。资源管理系统调用Addressables专家。

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:**
```markdown

文件扩展名/类型	调用的专家
游戏代码（.cs文件）	unity-specialist
着色器/材质文件（.shader、.shadergraph、.mat）	unity-shader-specialist
UI/界面文件（.uxml、.uss、Canvas预制件）	unity-ui-specialist
场景/预制件/关卡文件（.unity、.prefab）	unity-specialist
原生扩展/插件文件（.dll、原生插件）	unity-specialist
通用架构审核	unity-specialist


**Unreal：**
```markdown

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.

主专家: unreal-specialist
语言/代码专家: ue-blueprint-specialist（Blueprint图）或unreal-specialist（C++）
着色器专家: unreal-specialist（无专门着色器专家——主专家覆盖材质）
UI专家: ue-umg-specialist（UMG控件、CommonUI、输入路由、控件样式）
额外专家: ue-gas-specialist（Gameplay Ability System、属性、游戏效果），ue-replication-specialist（属性复制、RPC、客户端预测、网络代码）
路由说明: C++架构和广泛引擎决策调用主专家。Blueprint图架构和BP/C++边界设计调用Blueprint专家。所有能力和属性代码调用GAS专家。任何多人或网络系统调用复制专家。所有UI实现调用UMG专家。

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

undefined

文件扩展名/类型	调用的专家
游戏代码（.cpp、.h文件）	unreal-specialist
着色器/材质文件（.usf、.ush、材质资源）	unreal-specialist
UI/界面文件（.umg、UMG Widget Blueprints）	ue-umg-specialist
场景/预制件/关卡文件（.umap、.uasset）	unreal-specialist
原生扩展/插件文件（插件.uplugin、模块）	unreal-specialist
Blueprint图（.uasset BP类）	ue-blueprint-specialist
通用架构审核	unreal-specialist

undefined

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.

向用户展示填充后的偏好。对于Godot，需包含所选语言，并说明完整命名规范和专家路由表的位置：

"以下是[engine]的默认技术偏好（若为Godot则加[language]）。命名规范和专家路由表在本Skill的附录A中——我将应用[GDScript/C#/两者兼顾]变体。是否需要自定义这些设置，还是保存默认值？"

对于其他引擎，直接展示默认值，无需引用附录。

等待用户批准后再写入文件。

6. Determine Knowledge Gap

6. 识别知识缺口

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.

检查引擎版本是否可能超出LLM的训练数据。

已知大致覆盖范围（随模型更新而调整）：

LLM知识截止日期：2025年5月
Godot：训练数据可能覆盖至约4.3版本
Unity：训练数据可能覆盖至约2023.x / 早期6000.x版本
Unreal：训练数据可能覆盖至约5.3 / 早期5.4版本

将用户选择的版本与上述基线对比：

在训练数据范围内 →
```
低风险
```
—— 参考文档可选但推荐
接近边界 →
```
中风险
```
—— 推荐参考文档
超出训练数据 →
```
高风险
```
—— 必须使用参考文档

告知用户所属类别及原因。

7. Populate Engine Reference Docs

7. 填充引擎参考文档

If WITHIN training data (LOW RISK):

若在训练数据范围内（低风险）：

Create a minimal

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

markdown

undefined

创建极简版

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

：

markdown

undefined

[Engine] — Version Reference

[Engine] — 版本参考

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

字段	值
引擎版本	[version]
项目固定日期	[今日日期]
LLM知识截止日期	2025年5月
风险等级	低——版本在LLM训练数据范围内

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.

该引擎版本在LLM训练数据范围内。引擎参考文档可选，但如果Agent建议错误API，可稍后添加。

随时运行

/setup-engine refresh

填充完整参考文档。


请勿创建breaking-changes.md、deprecated-apis.md等文件——它们会增加上下文成本但价值极低。

If BEYOND training data (MEDIUM or HIGH RISK):

若超出训练数据范围（中风险或高风险）：

Create the full reference doc set by searching the web:

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

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.

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)

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.
For module files: Only create modules for subsystems where significant changes occurred. Don't create empty or minimal module files.

通过网络搜索创建完整的参考文档集：

搜索官方迁移/升级指南：

"[engine] [旧版本] to [新版本] migration guide"

```
"[engine] [version] breaking changes"
```
```
"[engine] [version] changelog"
```
```
"[engine] [version] deprecated API"
```

从官方文档获取并提取：
- 从训练截止版本到当前版本的每个版本间的破坏性变更
- 已弃用API及其替代方案
- 新功能和最佳实践

询问："我可以在

docs/engine-reference/<engine>/

下创建引擎参考文档吗？"

在写入任何文件前等待用户确认。

创建完整参考目录：

docs/engine-reference/<engine>/
├── VERSION.md              # 版本固定 + 知识缺口分析
├── breaking-changes.md     # 版本间破坏性变更
├── deprecated-apis.md      # "请勿使用X → 使用Y"表格
├── current-best-practices.md  # 训练截止后的新实践
└── modules/                # 子系统参考（按需创建）

填充每个文件：使用网络搜索到的真实数据，遵循现有参考文档的格式。每个文件必须包含"最后验证日期：[日期]"标题。
模块文件：仅在子系统发生重大变更时创建模块文件。请勿创建空文件或极简模块文件。

8. Update CLAUDE.md Import

8. 更新CLAUDE.md导入

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:

markdown

undefined

询问："我可以更新CLAUDE.md中的

导入以指向新的引擎参考吗？"

等待用户确认后，更新"Engine Version Reference"下的

导入，指向正确的引擎：

markdown

undefined

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.

---

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


若之前的导入指向不同引擎（例如从Godot切换到Unity），则更新它。

---

9. Update Agent Instructions

9. 更新Agent说明

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:

Read

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

Check deprecated APIs before suggesting code
Check breaking changes for relevant version transitions
Use WebSearch to verify uncertain APIs

在进行任何编辑前询问："我可以在引擎专家Agent文件中添加版本感知部分吗？"

对于所选引擎的专家Agent，验证是否存在"Version Awareness"部分。若不存在，按照现有Godot专家Agent的模式添加。

该部分应指示Agent：

读取

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

在建议代码前检查已弃用API
检查相关版本过渡的破坏性变更
使用WebSearch验证不确定的API

10. Refresh Subcommand

10. 刷新子命令

If invoked as

/setup-engine refresh

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

若调用

/setup-engine refresh

：

读取现有

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

获取当前引擎和版本

使用WebSearch检查：
- 上次验证后的新引擎版本
- 更新的迁移指南
- 新弃用的API
使用新发现更新所有参考文档
更新所有修改文件的"最后验证日期"
报告变更内容

11. Upgrade Subcommand

11. 升级子命令

If invoked as

/setup-engine upgrade [old-version] [new-version]

若调用

/setup-engine upgrade [old-version] [new-version]

：

Step 1 — Read Current Version State

步骤1 —— 读取当前版本状态

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.

读取

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

确认当前固定版本、风险等级，以及已记录的任何迁移指南URL。若未通过参数提供

old-version

，则使用该文件中的固定版本。

Step 2 — Fetch Migration Guide

步骤2 —— 获取迁移指南

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.

使用WebSearch和WebFetch查找

old-version

到

new-version

的官方迁移指南：

搜索：

"[engine] [old-version] to [new-version] migration guide"

搜索：

"[engine] [new-version] breaking changes changelog"

若VERSION.md中已记录迁移指南URL，则使用该URL；否则使用搜索到的URL。

提取：重命名的API、移除的API、变更的默认值、行为变更，以及任何"必须迁移"的项。

Step 3 — Pre-Upgrade Audit

步骤3 —— 升级前审核

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

扫描

src/

目录查找使用目标版本中已弃用或变更API的代码：

使用Grep搜索从迁移指南中提取的已弃用API名称（例如旧函数名、移除的节点类型、变更的属性名）
列出每个匹配的文件及找到的特定API引用

以表格形式展示审核结果：

升级前审核：[engine] [old-version] → [new-version]
==========================================================

需要修改的文件：
  文件                              | 发现的已弃用API       | 工作量
  --------------------------------- | -------------------------- | ------
  src/gameplay/player_movement.gd   | old_api_name               | 低
  src/ui/hud.gd                     | removed_node_type          | 中

需要注意的破坏性变更：
  - [迁移指南中的变更描述]
  - [迁移指南中的变更描述]

推荐迁移顺序（按依赖排序）：
  1. [依赖最少的系统/层优先]
  2. [下一个系统]
  ...

若在

src/

中未发现已弃用API，报告："在src/中未发现已弃用API使用——升级风险可能较低。"

Step 4 — Confirm Before Updating

步骤4 —— 更新前确认

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.

在进行任何变更前询问用户：

"升级前审核完成。发现[N]个文件使用已弃用API。是否继续将VERSION.md升级至[new-version]？（这将更新固定版本并添加迁移说明——不会修改任何源文件。源文件迁移需手动完成或通过任务故事进行。）"

等待用户明确确认后再继续。

Step 5 — Update VERSION.md

步骤5 —— 更新VERSION.md

After confirmation:

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
If
```
breaking-changes.md
```
or
```
deprecated-apis.md
```
exist in the engine reference directory, append the new version's changes to those files.

确认后：

更新
```
docs/engine-reference/<engine>/VERSION.md
```
：
- ```
引擎版本
```
  →
```
[new-version]
```
- ```
项目固定日期
```
  → 今日日期
- ```
最后文档验证日期
```
  → 今日日期
- 重新评估并更新
```
风险等级
```
  和
```
截止后版本时间线
```
  表格（若新版本超出LLM知识截止日期）
- 添加
```
## 迁移说明 —— [old-version] → [new-version]
```
  部分，包含：迁移指南URL、关键破坏性变更、本项目中发现的已弃用API，以及审核得出的推荐迁移顺序
若引擎参考目录中存在
```
breaking-changes.md
```
或
```
deprecated-apis.md
```
，将新版本的变更追加到这些文件中。

Step 6 — Post-Upgrade Reminder

步骤6 —— 升级后提醒

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

更新VERSION.md后输出：

VERSION.md已更新：[engine] [old-version] → [new-version]

后续步骤：
1. 迁移上述[N]个文件中已弃用的API使用
2. 升级实际引擎二进制文件后运行/setup-engine refresh，验证是否遗漏新的弃用项
3. 运行/architecture-review —— 引擎升级可能使引用特定API或引擎能力的ADR失效
4. 若任何ADR失效，运行/propagate-design-change更新下游任务故事

12. Output Summary

12. 输出总结

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 validate the core idea before writing GDDs
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.

设置完成后输出：

引擎设置完成
=====================
引擎：          [名称] [版本]
语言：        [GDScript | C# | GDScript + C# | C# | C++ + Blueprint]
知识风险：  [低/中/高]
参考文档：  [已创建/已跳过]
CLAUDE.md：       [已更新]
技术偏好：      [已创建/已更新]
Agent配置：    [已验证]

后续步骤：
1. 查看docs/engine-reference/<engine>/VERSION.md
2. [若来自/brainstorm] 运行/map-systems将你的概念分解为独立系统
3. [若来自/brainstorm] 运行/design-system编写每个系统的GDD（引导式，逐节编写）
4. [若来自/brainstorm] 运行/prototype [核心机制]在编写GDD前验证核心想法
5. [若全新开始] 运行/brainstorm探索你的游戏概念
6. 创建首个里程碑：/sprint-plan new

结论：完成 —— 引擎已配置，参考文档已填充。

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
When the user chose GDScript: copy the GDScript CLAUDE.md template from Appendix A1 exactly. NEVER add "C++ via GDExtension" to the Language field. GDScript projects may use GDExtension, but it is not a primary project language. The
```
godot-gdextension-specialist
```
in the routing table is available for when native extensions are needed — it does not make C++ a project language.

绝不猜测引擎版本——始终通过WebSearch或用户确认验证
绝不未经询问覆盖现有参考文档——追加或更新
若已有其他引擎的参考文档，替换前需询问用户
在编辑CLAUDE.md前始终向用户展示拟变更内容
若WebSearch结果不明确，展示给用户并让其决定
当用户选择GDScript时：严格从附录A1复制GDScript的CLAUDE.md模板。绝不在语言字段添加"C++ via GDExtension"。GDScript项目可能使用GDExtension，但它不是项目主语言。路由表中的
```
godot-gdextension-specialist
```
在需要原生扩展时可用——这并不使C++成为项目语言。

Appendix A — Godot Language Configuration

附录A —— Godot语言配置

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.

所有Godot特定的语言相关配置变体。参考第4节和第5节——仅当选择Godot作为引擎时相关。使用第4节中所选语言对应的子章节。

A1. CLAUDE.md Technology Stack Templates

A1. CLAUDE.md技术栈模板

GDScript:

markdown

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

Guardrail: When using this GDScript template, write the Language field as exactly "
GDScript
" — no additions. Do NOT append "C++ via GDExtension" or any other language. The C# template below includes GDExtension because C# projects commonly wrap native code; GDScript projects do not.

C#:

markdown

- **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#:

markdown

- **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

GDScript：

markdown

- **引擎**: Godot [version]
- **语言**: GDScript
- **构建系统**: SCons（引擎），Godot导出模板
- **资源管线**: Godot导入系统 + 自定义资源管线

防护规则: 使用此GDScript模板时，语言字段必须严格写为"
GDScript
"——不得添加其他内容。请勿追加"C++ via GDExtension"或任何其他语言。下方的C#模板包含GDExtension，因为C#项目通常包装原生代码；而GDScript项目不适用。

C#：

markdown

- **引擎**: Godot [version]
- **语言**: C#（.NET 8+，主要），C++ via GDExtension（仅原生插件）
- **构建系统**: .NET SDK + Godot导出模板
- **资源管线**: Godot导入系统 + 自定义资源管线

两者兼顾 —— GDScript + C#：

markdown

- **引擎**: Godot [version]
- **语言**: GDScript（游戏玩法/UI脚本），C#（性能关键系统），C++ via GDExtension（仅原生）
- **构建系统**: .NET SDK + Godot导出模板
- **资源管线**: Godot导入系统 + 自定义资源管线

A2. Naming Conventions

A2. 命名规范

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

GDScript：

类：PascalCase（例如：
```
PlayerController
```
）
变量/函数：snake_case（例如：
```
move_speed
```
）
信号：过去式snake_case（例如：
```
health_changed
```
）
文件：与类名匹配的snake_case（例如：
```
player_controller.gd
```
）
场景：与根节点匹配的PascalCase（例如：
```
PlayerController.tscn
```
）
常量：UPPER_SNAKE_CASE（例如：
```
MAX_HEALTH
```
）

C#：

类：PascalCase（
```
PlayerController
```
）——必须为
```
partial
```
公共属性/字段：PascalCase（
```
MoveSpeed
```
、
```
JumpVelocity
```
）
私有字段：
```
_camelCase
```
（
```
_currentHealth
```
、
```
_isGrounded
```
）
方法：PascalCase（
```
TakeDamage()
```
、
```
GetCurrentHealth()
```
）
信号委托：PascalCase +
```
EventHandler
```
后缀（
```
HealthChangedEventHandler
```
）
文件：与类名匹配的PascalCase（
```
PlayerController.cs
```
）
场景：与根节点匹配的PascalCase（
```
PlayerController.tscn
```
）
常量：PascalCase（
```
MaxHealth
```
、
```
DefaultMoveSpeed
```
）

两者兼顾 —— GDScript + C#：

.gd

文件使用GDScript规范，

.cs

文件使用C#规范。不存在混合语言文件——边界为单个文件。若不确定新系统应使用哪种语言，询问用户并将决策记录在

technical-preferences.md

中。

A3. Engine Specialists Routing

A3. 引擎专家路由

GDScript:

markdown

undefined

GDScript：

markdown

undefined

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.

主专家: godot-specialist
语言/代码专家: godot-gdscript-specialist（所有.gd文件）
着色器专家: godot-shader-specialist（.gdshader文件、VisualShader资源）
UI专家: godot-specialist（无专门UI专家——主专家覆盖所有UI）
额外专家: godot-gdextension-specialist（仅GDExtension / 原生C++绑定）
路由说明: 架构决策、ADR验证和跨领域代码审核调用主专家。代码质量、信号架构、静态类型强制执行和GDScript idioms调用GDScript专家。材质设计和着色器代码调用着色器专家。仅在涉及原生扩展时调用GDExtension专家。

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#:**
```markdown

文件扩展名/类型	调用的专家
游戏代码（.gd文件）	godot-gdscript-specialist
着色器/材质文件（.gdshader、VisualShader）	godot-shader-specialist
UI/界面文件（Control节点、CanvasLayer）	godot-specialist
场景/预制件/关卡文件（.tscn、.tres）	godot-specialist
原生扩展/插件文件（.gdextension、C++）	godot-gdextension-specialist
通用架构审核	godot-specialist


**C#：**
```markdown

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.

主专家: godot-specialist
语言/代码专家: godot-csharp-specialist（所有.cs文件）
着色器专家: godot-shader-specialist（.gdshader文件、VisualShader资源）
UI专家: godot-specialist（无专门UI专家——主专家覆盖所有UI）
额外专家: godot-gdextension-specialist（仅GDExtension / 原生C++绑定）
路由说明: 架构决策、ADR验证和跨领域代码审核调用主专家。代码质量、[Signal]委托模式、[Export]属性、.csproj管理和C#特定Godot idioms调用C#专家。材质设计和着色器代码调用着色器专家。仅在涉及原生C++插件时调用GDExtension专家。

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#:**
```markdown

文件扩展名/类型	调用的专家
游戏代码（.cs文件）	godot-csharp-specialist
着色器/材质文件（.gdshader、VisualShader）	godot-shader-specialist
UI/界面文件（Control节点、CanvasLayer）	godot-specialist
场景/预制件/关卡文件（.tscn、.tres）	godot-specialist
项目配置（.csproj、NuGet）	godot-csharp-specialist
原生扩展/插件文件（.gdextension、C++）	godot-gdextension-specialist
通用架构审核	godot-specialist


**两者兼顾 —— GDScript + C#：**
```markdown

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.

主专家: godot-specialist
GDScript专家: godot-gdscript-specialist（.gd文件——游戏玩法/UI脚本）
C#专家: godot-csharp-specialist（.cs文件——性能关键系统）
着色器专家: godot-shader-specialist（.gdshader文件、VisualShader资源）
UI专家: godot-specialist（无专门UI专家——主专家覆盖所有UI）
额外专家: godot-gdextension-specialist（仅GDExtension / 原生C++绑定）
路由说明: 跨语言架构决策及系统语言归属调用主专家。.gd文件调用GDScript专家。.cs文件和.csproj管理调用C#专家。在语言边界优先使用信号而非直接跨语言方法调用。

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

undefined

文件扩展名/类型	调用的专家
游戏代码（.gd文件）	godot-gdscript-specialist
游戏代码（.cs文件）	godot-csharp-specialist
跨语言边界决策	godot-specialist
着色器/材质文件（.gdshader、VisualShader）	godot-shader-specialist
UI/界面文件（Control节点、CanvasLayer）	godot-specialist
场景/预制件/关卡文件（.tscn、.tres）	godot-specialist
项目配置（.csproj、NuGet）	godot-csharp-specialist
原生扩展/插件文件（.gdextension、C++）	godot-gdextension-specialist
通用架构审核	godot-specialist

undefined