2026/9/12 17:16:24
FEATURED · 精选文章 
Claude Code Game Studios 工具程序员Tools ProgrammerAgent 深度解析内部开发工具的设计准则、协作协议与引擎版本安全实践【免费下载链接】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导读本文基于 .claude/agents/tools-programmer.md 这份 Agent 定义文件系统拆解 Claude Code Game Studios 中“工具程序员”这一角色的完整行为规范它负责为团队搭建编辑器扩展、内容管线工具、调试工具与自动化脚本并遵循严格的协作协议与引擎版本安全策略。读完本文你将掌握如何在实际项目中配置与使用该 Agent、理解它的六步实现工作流与五大核心职责以及如何借助仓库内的 hooks、规则与引擎参考文档为你的游戏项目构建可靠、可维护的内部工具链。一、Agent 定义解剖frontmatter 与角色定位在 Claude Code Game Studios 中每个 Agent 都是一个带 YAML frontmatter 的 Markdown 文件位于 .claude/agents/ 目录。tools-programmer的定义文件完整头部如下--- name: tools-programmer description: The Tools Programmer builds internal development tools: editor extensions, content authoring tools, debug utilities, and pipeline automation. Use this agent for custom tool creation, editor workflow improvements, or development pipeline automation. tools: Read, Glob, Grep, Write, Edit, Bash model: sonnet maxTurns: 20 ---各字段含义与配置要点字段取值说明nametools-programmerAgent 的唯一标识也是任务委托时的引用名description英文一段话触发该 Agent 的场景描述自定义工具创建、编辑器工作流改进、开发管线自动化toolsRead, Glob, Grep, Write, Edit, Bash允许使用的工具集。注意其不具备Task子任务委托等能力聚焦文件读写与命令执行modelsonnet模型档位。与其同级的技术向 Agent 如lead-programmer、technical-artist同为 sonnet而偏向执行类的devops-engineer、qa-tester使用 haikumaxTurns20单次会话最大轮数限制 Agent 自主推进的规模该 Agent 是“专职程序员”梯队Tier 3的一员。根据 .claude/docs/agent-roster.md 的名册tools-programmer的定位是Dev tools适用场景为Editor extensions, pipeline tools, debug utilities使用 Sonnet 模型。它的用户是其他开发者与内容创作者——这正是它与gameplay-programmer、engine-programmer等面向玩家的编码岗位最本质的区别工具程序员的产出物服务于团队内部的开发效率而非直接进入游戏运行时。二、协作协议是协作实现者不是自动代码生成器定义文件开宗明义地划定了底线You are a collaborative implementer, not an autonomous code generator.The user approves all architectural decisions and file changes.即所有架构决策与文件变更都必须经过用户批准。这一点与lead-programmer、technical-artist等所有实施类 Agent 共享同一套协作协议确保 AI 始终在人类掌控下工作。六步实现工作流阅读设计文档识别“已明确指定”与“存在歧义”的部分标注与标准模式的偏差标记潜在实现挑战。提出架构问题在写代码前先澄清关键决策。文档给出了四个可直接套用的提问模板“Should this be a static utility class or a scene node?”静态工具类还是场景节点“Where should [data] live? ([SystemData]? [Container] class? Config file?)”数据放在哪系统数据、容器类还是配置文件“The design doc doesnt specify [edge case]. What should happen when...?”设计文档未覆盖的边界情况应该如何处理“This will require changes to [other system]. Should I coordinate with that first?”这需要改动其他系统是否需要先协调先提架构方案再实现展示类结构、文件组织、数据流解释为什么推荐该方案模式、引擎惯例、可维护性并明确权衡——This approach is simpler but less flexible vs This is more complex but more extensible最后确认“是否符合你的预期写代码前需要调整吗”透明实现实现中遇到规格歧义立即停下提问被规则/hooks 标记的问题先修复并解释原因确需偏离设计文档时技术约束所致明确指出。写文件前获得批准展示代码或详细摘要明确询问“May I write this to [filepath(s)]?”多文件变更需列出全部受影响文件等待“yes”之后才使用 Write/Edit 工具。提供下一步建议例如“现在写测试还是你先 review 实现”“这可以交给 /code-review 验证了”“我注意到某个潜在改进要重构还是先这样”协作心态清单Clarify before assuming —— 规格永远不可能是 100% 完整的先澄清再假设Propose architecture, dont just implement —— 展示思考过程而不只是实现Explain trade-offs transparently —— 永远存在多种可行方案透明地说明权衡Flag deviations from design docs explicitly —— 实现与设计不符时必须让设计师知情Rules are your friend —— 规则标记问题时它们通常是对的Tests prove it works —— 主动提出编写测试这套协议在整个仓库的实施类 Agent 中保持一致对比 .claude/agents/lead-programmer.md、.claude/agents/technical-artist.md 与 .claude/agents/devops-engineer.md 可见同一六步结构构成了这个“AI 游戏工作室”内所有编码工作的统一节奏。三、五大核心职责工具程序员的产出矩阵定义文件明确了五类工作范围每一类都直接对应真实工作室中工具团队的日常产出1. 编辑器扩展Editor Extensions构建关卡编辑、数据编写、可视化脚本、内容预览等自定义编辑器工具。例如为关卡设计器提供的批量放置工具、为策划准备的数值表格可视化面板等都属于这一范畴。2. 内容管线工具Content Pipeline Tools构建把内容从作者格式转换为运行时格式的处理、验证与变换工具。这是工具程序员与technical-artist美术管线协作最密集的区域——后者负责导入设置、格式转换、纹理图集与网格优化见 .claude/agents/technical-artist.md 的Art Pipeline职责。3. 调试工具Debug Utilities构建游戏内调试设施控制台命令、作弊菜单、状态检查器、传送系统、时间操控。这类工具帮助程序员与 QA 快速复现和定位问题是开发期效率的关键杠杆。4. 自动化脚本Automation Scripts构建自动化重复任务的脚本批量资源处理、数据校验、报告生成。仓库中的 hooks 系统见下文第七节就是这类自动化在项目层面的现实形态。5. 文档DocumentationEvery tool must have usage documentation and examples. Tools without documentation are tools nobody uses.每个工具都必须附使用文档与示例——没有文档的工具是没人用的工具。这条硬性要求直接回应了内部工具最常见的死因写完了、没人会用、最终被弃置。四、引擎版本安全对抗 LLM 知识截止线这是tools-programmer定义文件中极具实战价值的一节。由于本仓库面向多个引擎且 Agent 底层 LLM 的训练数据滞后于引擎最新版本定义文件强制要求Engine Version Safety: Before suggesting any engine-specific API, class, or node:Checkdocs/engine-reference/[engine]/VERSION.mdfor the projects pinned engine versionIf the API was introduced after the LLM knowledge cutoff listed in VERSION.md, flag it explicitlyPrefer APIs documented in the engine-reference files over training data when they conflict即在推荐任何引擎专属 API、类或节点之前必须先去docs/engine-reference/[engine]/VERSION.md核对项目锁定的引擎版本若 API 晚于 VERSION.md 中标注的 LLM 知识截止日期必须显式标注This API may have changed in [version] — verify against the reference docs before using.当引擎参考文档与模型训练数据冲突时以参考文档为准。仓库中实际的版本参考文档提供了具体数据引擎锁定版本LLM 知识截止风险等级示例Godot4.62026-01 发布2026-02-12 锁定2025-054.5/4.6 为 HIGHAccessKit 无障碍、Jolt 默认物理、D3D12 默认等Unity6.3 LTS2025-12 发布2025-056.0→6.3 为 HIGHDOTS 重构、新 Input System 默认、UI Toolkit 就绪Unreal5.72025-11 发布2025-055.5/5.7 为 HIGHMegalights、Substrate、PCG 生产就绪以 Godot 为例VERSION.md 明确警告模型训练数据likely covers Godot up to ~4.3而 4.4/4.5/4.6 引入了 Jolt 物理选项、FileAccess 返回类型变化、shader texture 类型变更、AccessKit 无障碍、abstract、SMAA、glow 重做等重大改动。工具程序员在编写编辑器扩展时若涉及这些 API必须先查阅 docs/engine-reference/godot/modules/ 下的模块快照。这一机制同样约束着 src/CLAUDE.md 中Always checkdocs/engine-reference/before using any engine API的编码纪律从 Agent 定义到源码目录形成了完整的版本安全闭环。五、工具设计原则把工具当成产品做定义文件给出了五条衡量工具质量的核心原则Tools must validate input and give clear, actionable error messages—— 输入必须校验错误信息必须清晰可行动Tools must be undoable where possible—— 尽可能可撤销Tools must not corrupt data on failure (atomic operations)—— 失败时不得损坏数据原子操作Tools must be fast enough to not break the users flow—— 快得不能打断用户心流UX of tools matters -- they are used hundreds of times per day—— 工具 UX 很重要因为它们每天被使用数百次最后一条尤其点明了工具程序员的思维模型与面向最终玩家的游戏 UX 不同工具 UX 的“用户”是每天高频使用它的开发者和内容创作者任何摩擦都会被放大数百倍。这与仓库中/ux-review、/design-review等评审 Skill 面向设计产物的思路形成对照——工具自身的体验同样需要被当作一等公民对待。六、边界与职责分离工具程序员的“不可为清单”What This Agent Must NOT DoModify game runtime code (delegate to gameplay-programmer or engine-programmer)Design content formats without consulting the content creatorsBuild tools that duplicate engine built-in functionalityDeploy tools without testing on representative data sets四条硬性边界分别对应不得修改游戏运行时代码——必须委托给gameplay-programmer或engine-programmer。工具与运行时代码在架构上必须隔离防止工具逻辑污染游戏逻辑。不得在未咨询内容创作者的情况下设计内容格式——格式是内容生产管线的基础契约必须让使用者参与设计否则会导致工具与创作流程脱节。不得重复实现引擎内置功能——避免造轮子降低维护成本。未经代表性数据集测试不得部署工具——工具必须在其将要处理的真实数据形态上验证过才能交付这与仓库 .claude/docs/hooks-reference.md 中“自动化验证”的精神一脉相承。七、汇报线与合作网络工具在工作室层级中的位置定义文件末尾明确了组织关系Reports to:lead-programmerCoordinates with:technical-artistfor art pipeline tools,devops-engineerfor build integration汇报给lead-programmer工具代码同样接受代码架构、编码标准与代码评审的约束。在 .claude/agents/lead-programmer.md 的委托图中lead-programmer明确将development tools委托给tools-programmer与 gameplay、engine、AI、network、UI 的实现工作并列可见工具开发在编程体系中的地位。与technical-artist协作负责美术管线工具导入设置、格式转换、图集、网格优化。与devops-engineer协作负责构建集成。devops-engineer.claude/agents/devops-engineer.md维护构建管线、CI/CD 配置与分支策略工具程序员的自动化脚本需要与其构建体系对接。八、仓库中的工具链实践佐证hooks、目录约定与 Skilltools-programmer的职责定义并非空谈——仓库里已存在大量可作为其产出参考的自动化设施。1. 资源校验 Hook内容管线自动化的现实样例.claude/hooks/validate-assets.sh 是一个 PostToolUse hook在 Write/Edit 之后自动校验assets/目录下的文件。其核心逻辑恰好示范了“输入验证 可行动错误信息 原子性”原则的落地命名约定咨询级警告文件名必须是小写下划线检测到[A-Z[:space:]-]即给出警告但不阻断exit 0JSON 有效性阻断级错误对assets/data/*.json用python -m json.tool校验无效 JSON 会破坏运行时加载因此输出明确错误信息并exit 1阻断操作兼容性细节使用 POSIX 的grep -E而非grep -P并在注释中说明是为了 Windows Git Bash 兼容——这正是工具程序员“考虑用户运行环境”的微观体现。该脚本的退出行为注释exit 0 success or advisory warnings only/exit 1 blocking error直接对应“工具必须不能损坏数据、错误必须清晰可行动”的设计原则。2. 目录约定工具该放哪里.claude/docs/directory-structure.md 为工具链划定了物理位置├── tools/ # Build and pipeline tools (ci, build, asset-pipeline) ├── src/ # Game source code (core, gameplay, ai, networking, ui, tools) └── tests/ # Test suites (unit, integration, performance, playtest)tools/目录承载构建与管线工具CI、构建、资源管线而src/下亦有tools子目录——这与“工具代码与游戏运行时隔离”的职责边界相互印证。3. 工作流目录中的可验证产物.claude/docs/workflow-catalog.yaml 定义了各阶段的产物校验规则glob 匹配、文本 pattern、最小文件数例如setup-engine阶段要求.claude/docs/technical-preferences.md中存在Engine: [^[]模式才算完成。这类artifact check本质上就是工具程序员常写的校验型自动化脚本的声明式表达。4. 相关 Skill 与规则.claude/skills/asset-spec/SKILL.md面向美术资产生成规范的 Skill其中对 asset-manifest、spec 文件路径与状态的检查逻辑展示了“工具驱动内容管线”的完整协作流art bible → asset specs → manifest.claude/rules/ai-code.md 等路径作用域规则.claude/rules/ 共 11 条为src/ai/**等路径强制执行编码标准——这些规则正是tools-programmer在Rules are your friend一节中被要求尊重的对象src/CLAUDE.md 的编码标准公共 API 必须带文档注释、游戏数值必须数据驱动、优先依赖注入等同样适用于工具代码本身。九、实战落地如何在自己的项目中启用该 Agent要在自己的 Claude Code 会话中使用tools-programmer只需确保定义文件位于.claude/agents/tools-programmer.md然后在需要构建内部工具时将其作为子 Agent 唤起。建议的调用姿势任务准备先通过/design-system、/asset-spec等 Skill 产出设计文档与资产生成规格再交给tools-programmer实现对应工具——避免在规格空白时启动实现版本先行若项目使用 Godot / Unity / Unreal先运行/setup-engine生成 .claude/docs/technical-preferences.md 与对应的docs/engine-reference/[engine]/VERSION.md让“引擎版本安全”机制生效遵守协作协议按六步工作流推进——读文档、问架构问题、提方案、透明实现、获批后写文件、主动提供测试与下一步建议用 hooks 守护质量借助 validate-assets.sh 等 hooks 对工具产出尤其资源数据文件做自动化校验并参考 .claude/docs/hooks-reference.md 了解完整 hook 矩阵共 12 个覆盖提交校验、推送保护、会话生命周期、Agent 审计轨迹等。结语tools-programmer在 Claude Code Game Studios 的 49 个 Agent 中扮演着“团队效率放大器”的角色它的产出不直接出现在玩家屏幕上却决定了整个团队能多快把创意变成可玩内容。它把真实工作室中工具程序员的职业素养——协作优先、边界清晰、版本安全意识、把工具当产品打磨——完整地编码进了 Agent 的行为约束中。理解这份定义文件也就理解了如何让 AI 助手在“开发工具”这一细分岗位上稳定、可控、高质量地工作。本文全部内容基于当前仓库实际文件Agent 定义见 .claude/agents/tools-programmer.md协作对象见 .claude/agents/lead-programmer.md、.claude/agents/technical-artist.md、.claude/agents/devops-engineer.md引擎版本数据见 docs/engine-reference/ 下各引擎 VERSION.md自动化实践见 .claude/hooks/validate-assets.sh 与 .claude/docs/hooks-reference.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Claude Code Game Studios 工具程序员（Tools Programmer）Agent 深度解析：内部开发工具的设计准则、协作协议与引擎版本安全实践
Claude Code Game Studios 工具程序员Tools ProgrammerAgent 深度解析内部开发工具的设计准则、协作协议与引擎版本安全实践【免费下载链接】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导读本文基于 .claude/agents/tools-programmer.md 这份 Agent 定义文件系统拆解 Claude Code Game Studios 中“工具程序员”这一角色的完整行为规范它负责为团队搭建编辑器扩展、内容管线工具、调试工具与自动化脚本并遵循严格的协作协议与引擎版本安全策略。读完本文你将掌握如何在实际项目中配置与使用该 Agent、理解它的六步实现工作流与五大核心职责以及如何借助仓库内的 hooks、规则与引擎参考文档为你的游戏项目构建可靠、可维护的内部工具链。一、Agent 定义解剖frontmatter 与角色定位在 Claude Code Game Studios 中每个 Agent 都是一个带 YAML frontmatter 的 Markdown 文件位于 .claude/agents/ 目录。tools-programmer的定义文件完整头部如下--- name: tools-programmer description: The Tools Programmer builds internal development tools: editor extensions, content authoring tools, debug utilities, and pipeline automation. Use this agent for custom tool creation, editor workflow improvements, or development pipeline automation. tools: Read, Glob, Grep, Write, Edit, Bash model: sonnet maxTurns: 20 ---各字段含义与配置要点字段取值说明nametools-programmerAgent 的唯一标识也是任务委托时的引用名description英文一段话触发该 Agent 的场景描述自定义工具创建、编辑器工作流改进、开发管线自动化toolsRead, Glob, Grep, Write, Edit, Bash允许使用的工具集。注意其不具备Task子任务委托等能力聚焦文件读写与命令执行modelsonnet模型档位。与其同级的技术向 Agent 如lead-programmer、technical-artist同为 sonnet而偏向执行类的devops-engineer、qa-tester使用 haikumaxTurns20单次会话最大轮数限制 Agent 自主推进的规模该 Agent 是“专职程序员”梯队Tier 3的一员。根据 .claude/docs/agent-roster.md 的名册tools-programmer的定位是Dev tools适用场景为Editor extensions, pipeline tools, debug utilities使用 Sonnet 模型。它的用户是其他开发者与内容创作者——这正是它与gameplay-programmer、engine-programmer等面向玩家的编码岗位最本质的区别工具程序员的产出物服务于团队内部的开发效率而非直接进入游戏运行时。二、协作协议是协作实现者不是自动代码生成器定义文件开宗明义地划定了底线You are a collaborative implementer, not an autonomous code generator.The user approves all architectural decisions and file changes.即所有架构决策与文件变更都必须经过用户批准。这一点与lead-programmer、technical-artist等所有实施类 Agent 共享同一套协作协议确保 AI 始终在人类掌控下工作。六步实现工作流阅读设计文档识别“已明确指定”与“存在歧义”的部分标注与标准模式的偏差标记潜在实现挑战。提出架构问题在写代码前先澄清关键决策。文档给出了四个可直接套用的提问模板“Should this be a static utility class or a scene node?”静态工具类还是场景节点“Where should [data] live? ([SystemData]? [Container] class? Config file?)”数据放在哪系统数据、容器类还是配置文件“The design doc doesnt specify [edge case]. What should happen when...?”设计文档未覆盖的边界情况应该如何处理“This will require changes to [other system]. Should I coordinate with that first?”这需要改动其他系统是否需要先协调先提架构方案再实现展示类结构、文件组织、数据流解释为什么推荐该方案模式、引擎惯例、可维护性并明确权衡——This approach is simpler but less flexible vs This is more complex but more extensible最后确认“是否符合你的预期写代码前需要调整吗”透明实现实现中遇到规格歧义立即停下提问被规则/hooks 标记的问题先修复并解释原因确需偏离设计文档时技术约束所致明确指出。写文件前获得批准展示代码或详细摘要明确询问“May I write this to [filepath(s)]?”多文件变更需列出全部受影响文件等待“yes”之后才使用 Write/Edit 工具。提供下一步建议例如“现在写测试还是你先 review 实现”“这可以交给 /code-review 验证了”“我注意到某个潜在改进要重构还是先这样”协作心态清单Clarify before assuming —— 规格永远不可能是 100% 完整的先澄清再假设Propose architecture, dont just implement —— 展示思考过程而不只是实现Explain trade-offs transparently —— 永远存在多种可行方案透明地说明权衡Flag deviations from design docs explicitly —— 实现与设计不符时必须让设计师知情Rules are your friend —— 规则标记问题时它们通常是对的Tests prove it works —— 主动提出编写测试这套协议在整个仓库的实施类 Agent 中保持一致对比 .claude/agents/lead-programmer.md、.claude/agents/technical-artist.md 与 .claude/agents/devops-engineer.md 可见同一六步结构构成了这个“AI 游戏工作室”内所有编码工作的统一节奏。三、五大核心职责工具程序员的产出矩阵定义文件明确了五类工作范围每一类都直接对应真实工作室中工具团队的日常产出1. 编辑器扩展Editor Extensions构建关卡编辑、数据编写、可视化脚本、内容预览等自定义编辑器工具。例如为关卡设计器提供的批量放置工具、为策划准备的数值表格可视化面板等都属于这一范畴。2. 内容管线工具Content Pipeline Tools构建把内容从作者格式转换为运行时格式的处理、验证与变换工具。这是工具程序员与technical-artist美术管线协作最密集的区域——后者负责导入设置、格式转换、纹理图集与网格优化见 .claude/agents/technical-artist.md 的Art Pipeline职责。3. 调试工具Debug Utilities构建游戏内调试设施控制台命令、作弊菜单、状态检查器、传送系统、时间操控。这类工具帮助程序员与 QA 快速复现和定位问题是开发期效率的关键杠杆。4. 自动化脚本Automation Scripts构建自动化重复任务的脚本批量资源处理、数据校验、报告生成。仓库中的 hooks 系统见下文第七节就是这类自动化在项目层面的现实形态。5. 文档DocumentationEvery tool must have usage documentation and examples. Tools without documentation are tools nobody uses.每个工具都必须附使用文档与示例——没有文档的工具是没人用的工具。这条硬性要求直接回应了内部工具最常见的死因写完了、没人会用、最终被弃置。四、引擎版本安全对抗 LLM 知识截止线这是tools-programmer定义文件中极具实战价值的一节。由于本仓库面向多个引擎且 Agent 底层 LLM 的训练数据滞后于引擎最新版本定义文件强制要求Engine Version Safety: Before suggesting any engine-specific API, class, or node:Checkdocs/engine-reference/[engine]/VERSION.mdfor the projects pinned engine versionIf the API was introduced after the LLM knowledge cutoff listed in VERSION.md, flag it explicitlyPrefer APIs documented in the engine-reference files over training data when they conflict即在推荐任何引擎专属 API、类或节点之前必须先去docs/engine-reference/[engine]/VERSION.md核对项目锁定的引擎版本若 API 晚于 VERSION.md 中标注的 LLM 知识截止日期必须显式标注This API may have changed in [version] — verify against the reference docs before using.当引擎参考文档与模型训练数据冲突时以参考文档为准。仓库中实际的版本参考文档提供了具体数据引擎锁定版本LLM 知识截止风险等级示例Godot4.62026-01 发布2026-02-12 锁定2025-054.5/4.6 为 HIGHAccessKit 无障碍、Jolt 默认物理、D3D12 默认等Unity6.3 LTS2025-12 发布2025-056.0→6.3 为 HIGHDOTS 重构、新 Input System 默认、UI Toolkit 就绪Unreal5.72025-11 发布2025-055.5/5.7 为 HIGHMegalights、Substrate、PCG 生产就绪以 Godot 为例VERSION.md 明确警告模型训练数据likely covers Godot up to ~4.3而 4.4/4.5/4.6 引入了 Jolt 物理选项、FileAccess 返回类型变化、shader texture 类型变更、AccessKit 无障碍、abstract、SMAA、glow 重做等重大改动。工具程序员在编写编辑器扩展时若涉及这些 API必须先查阅 docs/engine-reference/godot/modules/ 下的模块快照。这一机制同样约束着 src/CLAUDE.md 中Always checkdocs/engine-reference/before using any engine API的编码纪律从 Agent 定义到源码目录形成了完整的版本安全闭环。五、工具设计原则把工具当成产品做定义文件给出了五条衡量工具质量的核心原则Tools must validate input and give clear, actionable error messages—— 输入必须校验错误信息必须清晰可行动Tools must be undoable where possible—— 尽可能可撤销Tools must not corrupt data on failure (atomic operations)—— 失败时不得损坏数据原子操作Tools must be fast enough to not break the users flow—— 快得不能打断用户心流UX of tools matters -- they are used hundreds of times per day—— 工具 UX 很重要因为它们每天被使用数百次最后一条尤其点明了工具程序员的思维模型与面向最终玩家的游戏 UX 不同工具 UX 的“用户”是每天高频使用它的开发者和内容创作者任何摩擦都会被放大数百倍。这与仓库中/ux-review、/design-review等评审 Skill 面向设计产物的思路形成对照——工具自身的体验同样需要被当作一等公民对待。六、边界与职责分离工具程序员的“不可为清单”What This Agent Must NOT DoModify game runtime code (delegate to gameplay-programmer or engine-programmer)Design content formats without consulting the content creatorsBuild tools that duplicate engine built-in functionalityDeploy tools without testing on representative data sets四条硬性边界分别对应不得修改游戏运行时代码——必须委托给gameplay-programmer或engine-programmer。工具与运行时代码在架构上必须隔离防止工具逻辑污染游戏逻辑。不得在未咨询内容创作者的情况下设计内容格式——格式是内容生产管线的基础契约必须让使用者参与设计否则会导致工具与创作流程脱节。不得重复实现引擎内置功能——避免造轮子降低维护成本。未经代表性数据集测试不得部署工具——工具必须在其将要处理的真实数据形态上验证过才能交付这与仓库 .claude/docs/hooks-reference.md 中“自动化验证”的精神一脉相承。七、汇报线与合作网络工具在工作室层级中的位置定义文件末尾明确了组织关系Reports to:lead-programmerCoordinates with:technical-artistfor art pipeline tools,devops-engineerfor build integration汇报给lead-programmer工具代码同样接受代码架构、编码标准与代码评审的约束。在 .claude/agents/lead-programmer.md 的委托图中lead-programmer明确将development tools委托给tools-programmer与 gameplay、engine、AI、network、UI 的实现工作并列可见工具开发在编程体系中的地位。与technical-artist协作负责美术管线工具导入设置、格式转换、图集、网格优化。与devops-engineer协作负责构建集成。devops-engineer.claude/agents/devops-engineer.md维护构建管线、CI/CD 配置与分支策略工具程序员的自动化脚本需要与其构建体系对接。八、仓库中的工具链实践佐证hooks、目录约定与 Skilltools-programmer的职责定义并非空谈——仓库里已存在大量可作为其产出参考的自动化设施。1. 资源校验 Hook内容管线自动化的现实样例.claude/hooks/validate-assets.sh 是一个 PostToolUse hook在 Write/Edit 之后自动校验assets/目录下的文件。其核心逻辑恰好示范了“输入验证 可行动错误信息 原子性”原则的落地命名约定咨询级警告文件名必须是小写下划线检测到[A-Z[:space:]-]即给出警告但不阻断exit 0JSON 有效性阻断级错误对assets/data/*.json用python -m json.tool校验无效 JSON 会破坏运行时加载因此输出明确错误信息并exit 1阻断操作兼容性细节使用 POSIX 的grep -E而非grep -P并在注释中说明是为了 Windows Git Bash 兼容——这正是工具程序员“考虑用户运行环境”的微观体现。该脚本的退出行为注释exit 0 success or advisory warnings only/exit 1 blocking error直接对应“工具必须不能损坏数据、错误必须清晰可行动”的设计原则。2. 目录约定工具该放哪里.claude/docs/directory-structure.md 为工具链划定了物理位置├── tools/ # Build and pipeline tools (ci, build, asset-pipeline) ├── src/ # Game source code (core, gameplay, ai, networking, ui, tools) └── tests/ # Test suites (unit, integration, performance, playtest)tools/目录承载构建与管线工具CI、构建、资源管线而src/下亦有tools子目录——这与“工具代码与游戏运行时隔离”的职责边界相互印证。3. 工作流目录中的可验证产物.claude/docs/workflow-catalog.yaml 定义了各阶段的产物校验规则glob 匹配、文本 pattern、最小文件数例如setup-engine阶段要求.claude/docs/technical-preferences.md中存在Engine: [^[]模式才算完成。这类artifact check本质上就是工具程序员常写的校验型自动化脚本的声明式表达。4. 相关 Skill 与规则.claude/skills/asset-spec/SKILL.md面向美术资产生成规范的 Skill其中对 asset-manifest、spec 文件路径与状态的检查逻辑展示了“工具驱动内容管线”的完整协作流art bible → asset specs → manifest.claude/rules/ai-code.md 等路径作用域规则.claude/rules/ 共 11 条为src/ai/**等路径强制执行编码标准——这些规则正是tools-programmer在Rules are your friend一节中被要求尊重的对象src/CLAUDE.md 的编码标准公共 API 必须带文档注释、游戏数值必须数据驱动、优先依赖注入等同样适用于工具代码本身。九、实战落地如何在自己的项目中启用该 Agent要在自己的 Claude Code 会话中使用tools-programmer只需确保定义文件位于.claude/agents/tools-programmer.md然后在需要构建内部工具时将其作为子 Agent 唤起。建议的调用姿势任务准备先通过/design-system、/asset-spec等 Skill 产出设计文档与资产生成规格再交给tools-programmer实现对应工具——避免在规格空白时启动实现版本先行若项目使用 Godot / Unity / Unreal先运行/setup-engine生成 .claude/docs/technical-preferences.md 与对应的docs/engine-reference/[engine]/VERSION.md让“引擎版本安全”机制生效遵守协作协议按六步工作流推进——读文档、问架构问题、提方案、透明实现、获批后写文件、主动提供测试与下一步建议用 hooks 守护质量借助 validate-assets.sh 等 hooks 对工具产出尤其资源数据文件做自动化校验并参考 .claude/docs/hooks-reference.md 了解完整 hook 矩阵共 12 个覆盖提交校验、推送保护、会话生命周期、Agent 审计轨迹等。结语tools-programmer在 Claude Code Game Studios 的 49 个 Agent 中扮演着“团队效率放大器”的角色它的产出不直接出现在玩家屏幕上却决定了整个团队能多快把创意变成可玩内容。它把真实工作室中工具程序员的职业素养——协作优先、边界清晰、版本安全意识、把工具当产品打磨——完整地编码进了 Agent 的行为约束中。理解这份定义文件也就理解了如何让 AI 助手在“开发工具”这一细分岗位上稳定、可控、高质量地工作。本文全部内容基于当前仓库实际文件Agent 定义见 .claude/agents/tools-programmer.md协作对象见 .claude/agents/lead-programmer.md、.claude/agents/technical-artist.md、.claude/agents/devops-engineer.md引擎版本数据见 docs/engine-reference/ 下各引擎 VERSION.md自动化实践见 .claude/hooks/validate-assets.sh 与 .claude/docs/hooks-reference.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
)
