CCGS/setup-engine技能深度解析通过technical-preferences.md一键配置引擎、语言与专家路由【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios/setup-engine是 Claude Code Game StudiosCCGS框架中的技术配置类工具技能utility skill负责把项目的引擎、语言、渲染后端、物理引擎、命名规范、性能预算与专家specialist agent指派一次性写入.claude/docs/technical-preferences.md并据此生成文件扩展名 → 专家的路由表。本文将以其行为规格文档 setup-engine.md 为主体结合 WORKFLOW-GUIDE.md、catalog.yaml 及框架内的测试规格文件完整解析该技能的工作流程、五个行为测试用例、静态断言与协作协议并说明它与/start、/test-setup等技能的衔接关系。1. 技能定位技术配置而非创意决策1.1 它解决什么问题一个 CCGS 驱动的游戏项目在立项后必须回答一系列技术问题用哪个引擎主语言是什么渲染后端用 Vulkan 还是 Metal物理引擎选哪个代码命名规范是 snake_case 还是 PascalCase性能预算定多少遇到具体文件时该把问题抛给哪个专家 Agent/setup-engine就是回答这些问题的入口。规格文档的开篇摘要Skill Summary给出了它的完整职责/setup-engineconfigures the projects engine, language, rendering backend, physics engine, specialist agent assignments, and naming conventions by populatingtechnical-preferences.md.也就是说它唯一的技术产物是technical-preferences.md——这份文件是后续几乎所有技能与 Agent 的技术事实来源。例如 team-combat.md 明确要求Engine Specialists section populatedPrimary: godot-specialist并在阶段 2 从该文件读取主引擎专家类型而非硬编码perf-profile.md 要求目标帧预算从technical-preferences.md读取not hardcodedasset-audit.md 则从该文件读取命名规范如snake_case、enemy_grunt_idle.png与资源大小预算。1.2 交互模式先展示草案再请求写入技能不是一次性无脑写入。规格明确指出对technical-preferences.md的每一个 section技能都先呈现一份草案draft然后询问May I write to \technical-preferences.md?获得用户批准后才更新技能接受可选的引擎参数如/setup-engine godot传入时跳过引擎选择步骤直接进入该引擎的语言、渲染等配置配置完成后技能还会根据所选引擎填充专家路由表specialist routing table即文件扩展名 → 负责 Agent的映射。1.3 无总监门禁Director Gate与 gate、readiness、team 类技能不同/setup-engine没有任何 director gate。规格文档明确说明None./setup-engineis a technical configuration skill. No director gates apply.理由很直接配置是纯技术性工具任务在项目初期甚至还没有完整的 Agent 层级不需要创意总监creative-director、技术总监technical-director等介入审查。这一点与 start.md 的定位一致——/start同样声明runs before any agent hierarchy exists。因此该技能的判定结果verdict只有一个当文件被完整写入后verdict 恒为 COMPLETE。2. 静态断言结构合规自动检查规格文档的第一组检查是静态断言Static Assertions由/skill-test static自动验证无需任何 fixture。这组断言确保了技能本体SKILL.md的结构符合框架模板参见 skill-test-spec.md断言含义必需的 frontmatter 字段name、description、argument-hint、user-invocable、allowed-tools≥ 2 个 phase 标题技能正文包含至少两个执行阶段标题包含判定关键字COMPLETE协作协议语言在更新technical-preferences.md之前必须包含May I write措辞下一步交接handoff结尾给出下一步技能建议如/brainstorm或/start取决于流程走向其中≥2 个 phase 标题保证了技能不是单步草率写入而是分阶段推进如阶段一读取现状、阶段二起草各 section、阶段三路由表填充、阶段四请求批准并写入。frontmatter 的argument-hint字段则对应了/setup-engine [engine]的可选参数设计——这正是规格中Respects engine argument when provided的行为基础。3. 五个行为测试用例逐条拆解行为规格的核心是五个测试用例Test Cases覆盖三种引擎的完整配置、已配置场景的部分重配、以及无门禁验证。每个用例都包含 fixture前置状态、input、expected behavior 与 assertions可勾选断言最终由/skill-test spec setup-engine逐条判定 PASS/FAIL/PARTIAL见 README.md 的使用说明。3.1 Case 1Godot 4 GDScript —— 完整引擎配置Fixturetechnical-preferences.md仅含占位符传入引擎参数godot。Input/setup-engine godot预期行为链因为已提供参数技能跳过引擎选择步骤呈现 Godot 的语言选项GDScript 或 C#用户选择 GDScript技能起草全部引擎相关 sectionengine/language/rendering/physics 字段、命名规范GDScript 用snake_case、专家指派godot-specialist、gdscript-specialist、godot-shader-specialist等填充路由表.gd→ gdscript-specialist.gdshader→ godot-shader-specialist.tscn→ godot-specialist询问May I write to \technical-preferences.md?批准后写入文件verdict 为 COMPLETE。断言要点Engine 字段必须是 Godot 4而非占位符Language 为 GDScript命名规范为 snake_case路由表包含.gd、.gdshader、.tscn三条记录专家均已指派写入前必须询问 May I writeverdict 为 COMPLETE。这与 WORKFLOW-GUIDE.md 的说明完全吻合——选定 Godot 后agents likegodot-specialist,godot-gdscript-specialist, andgodot-shader-specialistbecome your go-to experts而路由表正是让这些专家在后续文件处理中被正确调度的机制。3.2 Case 2Unity C# —— Unity 专属配置Fixturetechnical-preferences.md仅含占位符传入参数unity。Input/setup-engine unity预期行为Engine 设为 UnityLanguage 设为 C#命名规范采用 C# 惯例PascalCase 用于类名camelCase 用于字段专家指派引用unity-specialist、csharp-specialist注意规格中此处提到的csharp-specialist对应仓库 agents/engine/unity 目录下以 unity- 为前缀的专家族以及框架对 C# 语言专家的通用引用路由表.cs→ csharp-specialist.asmdef→ unity-specialist.unity场景→ unity-specialist询问 May I write 并在批准后写入。断言要点Engine 必须是 Unity而非 Godot 或 Unreal路由表包含.cs与.unity条目verdict 为 COMPLETE。值得注意.asmdefAssembly Definition是 Unity 独有的程序集定义文件路由到 unity-specialist 体现了路由表引擎特有文件类型 → 引擎特有专家的设计原则与 test-setup.md 中Unity 项目生成Tests/Tests.asmdef与Tests/Editor/EditorTests.asmdef的引擎差异化处理一脉相承。3.3 Case 3Unreal Blueprint —— Unreal 专属配置Fixturetechnical-preferences.md仅含占位符传入参数unreal。Input/setup-engine unreal预期行为Engine 设为Unreal Engine 5主语言设为Blueprint可视化脚本专家指派引用unreal-specialist、blueprint-specialist路由表.uasset→ blueprint-specialist 或 unreal-specialist.umap→ unreal-specialist性能预算使用 Unreal 默认值预置例如更高的 draw call 预算询问 May I write 并写入verdict 为 COMPLETE。断言要点Engine 为 Unreal Engine 5路由表包含.uasset与.umapBlueprint 专家已指派。这里体现出性能预算的引擎差异化默认值Unreal 的渲染管线Deferred Shading、Nanite通常允许比 Godot/Unity 更高的 draw call 预算因此technical-preferences.md中 Performance Budgets section 会随引擎不同而预置不同基线。后续如 technical-artist.md 的测试案例中就以2ms GPU frame budget, max 200 draw calls这类来自technical-preferences.md的预算作为优化任务的输入可见预算一旦配置就会成为各 Agent 的硬约束。3.4 Case 4引擎已配置 —— 仅重配指定 sectionFixturetechnical-preferences.md已完整配置为 Godot 4未传引擎参数。Input/setup-engine预期行为技能读取technical-preferences.md检测到引擎已完整配置Godot 4报告Engine already configured as Godot 4 GDScript提供选项整体重配或仅重配指定 sectionEngine/Language、Naming Conventions、Specialists、Performance Budgets 四类用户选择 Reconfigure Performance Budgets only仅更新性能预算 section其余字段保持不动询问 May I write 并写入。断言要点技能不会在仅请求 section 更新时覆盖全部字段提供 section 级重配选项写入的文件只修改选中 sectionverdict 为 COMPLETE。这个用例是非破坏性更新的关键保障technical-preferences.md可能已被后续工作流依赖如 dev-story.md 要求.claude/docs/technical-preferences.md已配置引擎与语言team-ui.md 需要读取引擎 UI 专家配置因此只动被请求的部分能避免破坏其他环节已建立的技术事实。这与/start的 Case 2已配置项目提供 skip / reconfigure 选项构成一致的检测现状 → 提供选项 → 绝不默认覆盖模式。3.5 Case 5总监门禁检查 —— 无门禁纯工具技能Fixture全新项目未配置任何引擎。Input/setup-engine godot预期行为技能完成完整引擎配置全程不产生任何 director Agent输出中不出现任何 gate ID如 CD-、TD-、AD-、PR-。断言要点未调用任何总监门禁不出现门禁跳过消息在没有任何门禁检查的情况下 verdict 即达 COMPLETE。值得注意规格中的措辞No gate skip messages appear不出现门禁跳过消息——强调门禁是天然不存在gates are absent而非存在但被抑制。这正是工具类技能与 gate/review 类技能的本质区别后者必须触发总监面板如 gate-check 的 full/lean/solo 三模式而 setup-engine 从设计上就不属于创意/技术审查流程。4. 协议合规协作写入的六条铁律规格文档的 Protocol Compliance 章节汇总了技能必须遵守的协作协议写入前先呈现配置草案Presents draft configuration before asking to write写入前必须询问May I write to \technical-preferences.md?提供引擎参数时尊重参数跳过选择步骤检测已有配置提供部分重配能力路由表必须覆盖所选引擎的所有关键文件类型文件写入后 verdict 为 COMPLETE。这六条与模板 skill-test-spec.md 中 Protocol Compliance 的要求May I write、先呈现草案、结尾给出下一步建议、未经批准不自动建文件完全对齐也呼应了 CCGS 框架collaborative protocol协作协议的通用设计——/start、/test-setup同样遵循逐文件 May I write 的审批模式。5. 覆盖率说明规格的边界与刻意留白Coverage Notes 章节诚实标注了三个未被单独测试的变体这对理解规格的意图很重要Godot 4 C# 变体流程与 Case 1 相同但命名规范不同且专家指派为godot-csharp-specialist。该变体不单独测试——规格假设语言选择步骤GDScript vs C#已被 Case 1 覆盖C# 分支只是同一流程的参数化结果。仓库 agents/engine/godot 目录下的godot-csharp-specialist.md正是该分支对应的专家定义引擎版本知识缺口警告例如docs/engine-reference/godot/VERSION.md对 Godot 4.6 的knowledge gap warningLLM 训练数据可能早于引擎版本由技能在执行时浮现但不做断言测试——因为它依赖外部版本数据而非固定行为性能预算默认值按引擎区分的具体数值如 Unreal 的 draw call 预算由技能写入但精确默认值不参与断言测试避免规格因引擎迭代而过早固化。这种行为可断言、数值不固化的分层策略保证了规格在引擎版本演进时仍能长期有效。该技能在 catalog.yaml 中注册name: setup-enginespec指向本规格文件纳入框架的覆盖追踪体系。6. 在完整工作流中的位置start → setup-engine → 一切依赖引擎的技能6.1 上游/start的显式交接/setup-engine通常不是项目的第一站。首次启动时start.md 负责询问项目名 → 呈现三个引擎选项Godot 4、Unity、Unreal Engine 5→ 创建初始目录结构与 CLAUDE.md 桩文件 → 最后显式路由到/setup-engine [chosen-engine]把用户刚选的引擎作为参数传入。WORKFLOW-GUIDE.md 给出了典型调用/setup-engine # 交互式选择引擎 /setup-engine godot 4.6 # 直接指定引擎与版本后者在引擎选择步骤被跳过的同时还能把版本号一起钉住version-pinned并触发docs/engine-reference/下对应版本的参考文档创建。这也是规格 Case 1Engine argument provided → skips engine-selection step在真实工作流中的来源。6.2 下游引擎配置是其他技能的前置条件配置完成后technical-preferences.md成为全项目技术配置的单一事实源/test-setuptest-setup.md读取引擎配置决定测试框架形态Godot 生成 GdUnit4 runnergodot --headless --script tests/gdunit4_runner.gdUnity 生成带.asmdef的 EditMode/PlayMode 测试结构Unreal 生成 headless runner若引擎未配置它会报告Engine not configured — cannot scaffold engine-specific test framework并建议先运行/setup-engineteam 类技能如 team-combat.md从该文件的 Engine Specialists section 读取主引擎专家类型来决定 spawn 哪个专家 Agentanalysis 类技能如 asset-audit.md、perf-profile.md读取命名规范、资源格式与性能预算作为审计基准。因此可以说/setup-engine是 CCGS 技术链路的起点——没有它/test-setup无法搭建测试、team 技能无法确定专家人选、analysis 技能没有审计基准。它用一次协作式配置把引擎事实注入整个框架让后续 70 技能与 49 个 Agent 都能基于同一份technical-preferences.md协同工作而不是各自猜测项目的技术栈。7. 总结/setup-engine的规格文档刻画了一个典型的高杠杆、低门槛的 utility 技能以technical-preferences.md为唯一产出物通过先草案、后 May I write的协作协议完成引擎/语言/渲染/物理/命名/专家/性能预算/路由表的全量配置用五个行为用例锁定三种引擎的差异化行为Godot 的 snake_case 与.gd路由、Unity 的 C# 命名与.asmdef、Unreal 的 Blueprint 与.uasset以及已配置则按 section 部分重配的非破坏性更新同时刻意保持无门禁、无固定数值断言的轻量约束。它是理解 CCGS 如何把技术栈决策形式化为可测试、可复现、可交接的 Agent 工作流的最佳切片——后续所有引擎相关技能都可以追溯到这份文件被/setup-engine写入的那一刻。【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考