Claude-Code-Game-Studios 技术总监 Agent 测试规格全解析TD 门禁判定、领域边界与协议合规验证【免费下载链接】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-Code-Game-StudiosCCGS框架中技术总监technical-directorAgent 的行为测试规格文档位于 CCGS Skill Testing Framework/agents/directors/technical-director.md并结合该 Agent 的真实定义文件.claude/agents/technical-director.md与相关技能规格说明如何验证一个负责架构决策与技术可行性把关的高层 Agent 是否行为正确。读者将掌握TD 系列门禁Gate判定词汇与输出格式、领域边界与越权控制、冲突升级路径以及完整的行为测试用例设计与断言写法。一、测试规格的定位为 Agent 本身编写行为契约CCGS 将 Claude Code 组织成完整的游戏工作室——49 个 AI Agent、72 个流程技能与一套协调系统。与测试用框架做出的游戏不同CCGS Skill Testing Framework/README.md 明确说明该框架测试的是skills 与 agents 本身且整个目录是自包含、可选的删除它不影响.claude/下任何依赖。每个 Agent 的行为规格behavioral spec存放于CCGS Skill Testing Framework/agents/下按层级分目录directors、leads、specialists、operations 等technical-director 属于directors/这一最高决策层。规格文件遵循 CCGS Skill Testing Framework/templates/agent-test-spec.md 模板的五段式结构Agent Summary领域声明、Static Assertions静态断言、Test Cases行为测试用例、Protocol Compliance协议合规、Coverage Notes覆盖缺口。其登记入口位于 CCGS Skill Testing Framework/catalog.yamlspec字段指向本文档运行/skill-test spec technical-director即可按此规格对 Agent 进行行为评估。二、Agent Summary技术总监的领域边界与门禁清单规格开篇用域归属 / 非归属 / 模型层级 / 门禁 ID四要素界定 Agent 的身份Domain owned拥有系统架构决策、技术可行性评估、ADRArchitecture Decision Record监督与审批、引擎风险评估、技术阶段门禁technical phase gate。Does NOT own不拥有游戏设计决策归 creative-director / game-designer、创意方向、视觉美术风格、生产排期归 producer。Model tierOpus 层级——理由是多文档综合multi-document synthesis与高风险的架构及阶段门禁裁决需要最强模型。实际 Agent 定义 .claude/agents/technical-director.md 的 frontmatter 中model: opus与之吻合并配置maxTurns: 30、memory: user。Gate IDs handled负责的门禁TD-SYSTEM-BOUNDARY系统边界、TD-FEASIBILITY可行性、TD-ARCHITECTURE架构、TD-ADR架构决策记录审批、TD-ENGINE-RISK引擎风险、TD-PHASE-GATE阶段门禁。注意一个细节Agent 定义文件 .claude/agents/technical-director.md 的 Gate Verdict Format 一节还列出了TD-CHANGE-IMPACT、TD-MANIFEST两个调用场景说明门禁 ID 集合在行为契约与运行时指令两处略有差异——这正是测试规格存在的意义把可验证的行为边界固定下来。领域边界还延伸到 Agent 定义中的职责清单Key Responsibilities架构所有权所有大系统必须有经其审批的 ADR、第三方库/中间件/引擎特性技术评估、性能预算制定帧时间、内存、加载时间、网络带宽、技术风险登记册维护、跨系统接口契约定义、代码质量标准与测试要求、技术债管理。与之配套的决策框架六条标准Correctness / Simplicity / Performance / Maintainability / Testability / Reversibility和Must NOT Do清单不做创意决策、不直接写玩法代码、不管理排期、不审批游戏设计共同构成了测试用例可引用的行为基线。三、静态断言无需夹具的结构性验证Static Assertions 部分列出了通过读取 .claude/agents/technical-director.md 的 frontmatter 即可自动核验的四项检查description:字段存在且为领域专用引用 architecture、feasibility、ADR而非泛化描述——实际 frontmatter 中确实写明owns all high-level technical decisions including engine architecture, technology choices, performance strategy, and technical risk management且tools配置为Read, Glob, Grep, Write, Edit, Bash, WebSearch。allowed-tools:列表允许 Read 用于架构文档Bash 仅在需要技术检查时使用——与 frontmatter 工具集一致。模型层级为 Opus规格按协调规则要求directors with gate synthesis Opus。Agent 定义不声称拥有游戏设计或创意方向决策权。这组断言的特点是全部可离线核验不依赖夹具fixture与 CCGS Skill Testing Framework/skills/gate/gate-check.md 中由/skill-test static自动核验的机制对应是最低成本的第一道质量闸门。四、五个行为测试用例详解规格的核心是五个场景化用例每个用例给出 Scenario场景、Expected期望行为、Assertions断言清单可执行后给出 PASS / FAIL / PARTIAL 结论。Case 1域内请求——输出格式正确TD-ARCHITECTURE场景提交Combat System架构文档采用分层设计input layer → game logic layer → presentation layer各层接口清晰请求标记TD-ARCHITECTURE。期望返回TD-ARCHITECTURE: APPROVE理由确认系统边界分离正确、接口定义良好。关键断言判定词严格取 APPROVE / CONCERNS / REJECT 之一判定词以TD-ARCHITECTURE: APPROVE令牌格式出现而非散落在段落中的散文式结论理由必须具体引用分层结构与接口定义拒绝泛泛的架构建议输出不越出技术范围——不评论机制是否有乐趣或是否符合创意愿景。这与 Agent 定义中的 Gate Verdict Format 完全呼应[GATE-ID]: APPROVE必须独占一行、位于回复首行calling skill reads the first line for the verdict token即下游技能靠解析首行令牌做自动化判定所以格式即协议。Case 2域外请求——重定向或升级对话脚本评审场景Writer 请求技术总监评审并批准开场过场动画的对话脚本。期望Agent 拒绝评价对话质量重定向到 narrative-director。关键断言不对对话内容或结构做任何有约束力的决定明确指名narrative-director为正确处理者对应真实 Agent .claude/agents/narrative-director.md可以提示影响对话的技术约束如本地化字符串长度限制、数据格式但所有内容决策一律让渡。该用例验证的是协作协议中的重定向能力Agent 识别跨域请求 → 指名正确归属 → 不静默处理杜绝顺手把别家活干了的越权。Case 3门禁判定——正确词汇与算法复杂度引用TD-FEASIBILITY场景一个多人机制要求每帧对所有活跃实体做 raycast 视线检测在目标玩家规模大区域内 1000 实体下为每帧 O(n²) 复杂度。请求标记TD-FEASIBILITY。期望返回TD-FEASIBILITY: CONCERNS并具体引用 O(n²) 复杂度与在目标帧率下不可行的实体数量阈值。关键断言判定词严格为三选一令牌格式TD-FEASIBILITY: CONCERNS理由包含具体的算法复杂度关切与实体数量阈值不能只说性能可能有问题至少提出一种替代方案如空间分区 spatial partitioning、兴趣管理 interest management但不强制指定采用哪一个。这是技术可行性门禁最典型的形态既要有量化依据复杂度 数量阈值又要保持咨询者身份给选项不给命令与 Agent 定义中present 2-3 strategic options…the user chooses的协作哲学一致。Case 4冲突升级——正确的上级仲裁者场景game-designer 想为每个背包物品加实时物理模拟数百物品同屏。技术总监评估为技术代价高昂、提议简化game-designer 反对认为这对游戏手感至关重要。期望技术总监清楚陈述技术代价与约束提出能近似还原手感的替代实现方案但把这个代价值不值得的最终设计优先级判断明确让渡给 creative-director——作为玩家体验权衡的仲裁者。关键断言技术关切要具体性能预算、估算代价至少提一个降低成本且保留意图的替代方案明确让渡值不值得付这个代价给 creative-director不单方面砍功能不声称有权否决 game-designer 的设计意图。该用例对应的正是 Agent 定义中的委托/升级映射技术总监是 cross-system technical conflict 的 escalation target但设计优先级冲突的最终仲裁者是 creative-director对应 .claude/agents/creative-director.md。注意与模板中 Case 4escalates to the shared parent (or creative-director / technical-director)的通用表述相比本规格把上级明确固定为 creative-director更精确。Case 5上下文透传——使用给定上下文而非泛泛而谈场景Agent 收到包含目标平台约束的门禁上下文块移动端、60fps 目标、2GB 内存上限、不支持 compute shader。提案架构包含 GPU-driven rendering pipeline。期望评估引用给定硬件约束识别 compute shader 依赖与平台约束不兼容返回带具体引证的 CONCERNS 或 REJECT。关键断言引用具体平台约束mobile、2GB RAM、no compute shaders不脱离给定约束给出泛化性能建议正确识别与平台约束冲突的架构组件判定理由绑定给定上下文而非套话式警告。该用例与模板 Case 5Agent uses provided context rather than re-asking for it一致验证的是门禁裁决的情境化质量——这是区分真门禁与模板复读机的关键测试。五、协议合规清单与门禁生态Protocol Compliance 将上述行为浓缩为五条全局契约任何一次调用都应满足仅使用 APPROVE / CONCERNS / REJECT 判定词汇不越出声明的技术领域设计优先级冲突让渡给 creative-director输出使用门禁 ID如TD-FEASIBILITY: CONCERNS而非散文式结论不做有约束力的游戏设计或创意方向决定。将 technical-director 放回门禁生态看其角色远不止单个 Agent阶段门禁CCGS Skill Testing Framework/skills/gate/gate-check.md 的 Case 5 规定full评审模式下/gate-check会并行唤起四位总监的 PHASE-GATE 判定CD-PHASE-GATE、TD-PHASE-GATE、PR-PHASE-GATE、AD-PHASE-GATE任一总监返回 CONCERNS 则整体门禁至少为 CONCERNSsolo模式则输出[TD-PHASE-GATE] skipped — Solo mode后仅凭产物/质量检查判定。这解释了本规格 Coverage Notes 中TD-PHASE-GATE 涉及多子门禁综合、暂缓覆盖的原因——它是更上层技能的集成行为。ADR 审批CCGS Skill Testing Framework/skills/authoring/architecture-decision.md 规定在full模式下 ADR 草稿完成后TD-ADR 与 LP-FEASIBILITY 两门禁并行唤起TD-ADR 返回 CONCERNS 时 ADR 状态保持 Proposed 而非 Accepted。这正好对应本规格 Coverage Notes 中TD-ADR 尚未覆盖的缺口——技能规格已定义其行为Agent 规格尚未补齐对应用例。输出格式Agent 定义要求架构决策按 ADR 格式输出Title / Status / Context / Decision / Consequences / Performance Implications / Alternatives ConsideredStatus 取值 Proposed / Accepted / Deprecated / Superseded——这是门禁判定之外技术总监产出物的事实标准。六、覆盖缺口已知未测领域与演进方向Coverage Notes 诚实列出了规格尚未覆盖的四个区域也是后续补充测试用例的清单TD-ADR 未覆盖应在/architecture-decision技能产出 ADR 文档后补充专门用例如上文所述技能侧 CCGS Skill Testing Framework/skills/authoring/architecture-decision.md 已定义 TD-ADR 行为Agent 侧尚未同步。TD-ENGINE-RISK 未覆盖针对特定引擎版本的评估如 Godot 4.6 截断后 API推迟到 engine-specialist 集成测试对应引擎参考文档 docs/engine-reference/godot/VERSION.md 等版本资料。TD-PHASE-GATE 未覆盖涉及多个子门禁结果综合的完整技术阶段推进判定属于集成级行为。多域架构评审未覆盖同时触及 TD-ARCHITECTURE 与 TD-ENGINE-RISK 的交叉场景。七、如何在框架中运行与演进本规格查看 Agent 定义.claude/agents/technical-director.md 是运行时行为本体本规格文档 CCGS Skill Testing Framework/agents/directors/technical-director.md 是行为契约。执行行为测试在仓库根目录对 Claude 发起/skill-test spec technical-director框架将按本文档的断言逐条评估/skill-test audit可查看全量 agents skills 的 has-spec / last tested / result 覆盖总览见 CCGS Skill Testing Framework/README.md。补充用例按 CCGS Skill Testing Framework/templates/agent-test-spec.md 模板新增用例并在 CCGS Skill Testing Framework/catalog.yaml 中登记随后运行/skill-test spec technical-director校验。约束提醒本目录自包含且可选可整体移除而不影响.claude/依赖CCGS Skill Testing Framework/README.md 中有明确说明。结语technical-director 的测试规格是 CCGS给 Agent 写行为契约理念的典型样本用TD-系列门禁 ID 固定输出协议、用领域边界约束职权、用五类用例覆盖域内正确输出、域外重定向、量化判定、冲突升级、上下文透传五种核心行为再以覆盖缺口清单指引后续演进。对于任何试图把 LLM Agent 引入高风险技术决策流程的团队这套规格-断言-用例-合规-缺口的结构本身就是一份可复用的质量保障模板。【免费下载链接】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 技术总监 Agent 测试规格全解析：TD 门禁判定、领域边界与协议合规验证
Claude-Code-Game-Studios 技术总监 Agent 测试规格全解析TD 门禁判定、领域边界与协议合规验证【免费下载链接】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-Code-Game-StudiosCCGS框架中技术总监technical-directorAgent 的行为测试规格文档位于 CCGS Skill Testing Framework/agents/directors/technical-director.md并结合该 Agent 的真实定义文件.claude/agents/technical-director.md与相关技能规格说明如何验证一个负责架构决策与技术可行性把关的高层 Agent 是否行为正确。读者将掌握TD 系列门禁Gate判定词汇与输出格式、领域边界与越权控制、冲突升级路径以及完整的行为测试用例设计与断言写法。一、测试规格的定位为 Agent 本身编写行为契约CCGS 将 Claude Code 组织成完整的游戏工作室——49 个 AI Agent、72 个流程技能与一套协调系统。与测试用框架做出的游戏不同CCGS Skill Testing Framework/README.md 明确说明该框架测试的是skills 与 agents 本身且整个目录是自包含、可选的删除它不影响.claude/下任何依赖。每个 Agent 的行为规格behavioral spec存放于CCGS Skill Testing Framework/agents/下按层级分目录directors、leads、specialists、operations 等technical-director 属于directors/这一最高决策层。规格文件遵循 CCGS Skill Testing Framework/templates/agent-test-spec.md 模板的五段式结构Agent Summary领域声明、Static Assertions静态断言、Test Cases行为测试用例、Protocol Compliance协议合规、Coverage Notes覆盖缺口。其登记入口位于 CCGS Skill Testing Framework/catalog.yamlspec字段指向本文档运行/skill-test spec technical-director即可按此规格对 Agent 进行行为评估。二、Agent Summary技术总监的领域边界与门禁清单规格开篇用域归属 / 非归属 / 模型层级 / 门禁 ID四要素界定 Agent 的身份Domain owned拥有系统架构决策、技术可行性评估、ADRArchitecture Decision Record监督与审批、引擎风险评估、技术阶段门禁technical phase gate。Does NOT own不拥有游戏设计决策归 creative-director / game-designer、创意方向、视觉美术风格、生产排期归 producer。Model tierOpus 层级——理由是多文档综合multi-document synthesis与高风险的架构及阶段门禁裁决需要最强模型。实际 Agent 定义 .claude/agents/technical-director.md 的 frontmatter 中model: opus与之吻合并配置maxTurns: 30、memory: user。Gate IDs handled负责的门禁TD-SYSTEM-BOUNDARY系统边界、TD-FEASIBILITY可行性、TD-ARCHITECTURE架构、TD-ADR架构决策记录审批、TD-ENGINE-RISK引擎风险、TD-PHASE-GATE阶段门禁。注意一个细节Agent 定义文件 .claude/agents/technical-director.md 的 Gate Verdict Format 一节还列出了TD-CHANGE-IMPACT、TD-MANIFEST两个调用场景说明门禁 ID 集合在行为契约与运行时指令两处略有差异——这正是测试规格存在的意义把可验证的行为边界固定下来。领域边界还延伸到 Agent 定义中的职责清单Key Responsibilities架构所有权所有大系统必须有经其审批的 ADR、第三方库/中间件/引擎特性技术评估、性能预算制定帧时间、内存、加载时间、网络带宽、技术风险登记册维护、跨系统接口契约定义、代码质量标准与测试要求、技术债管理。与之配套的决策框架六条标准Correctness / Simplicity / Performance / Maintainability / Testability / Reversibility和Must NOT Do清单不做创意决策、不直接写玩法代码、不管理排期、不审批游戏设计共同构成了测试用例可引用的行为基线。三、静态断言无需夹具的结构性验证Static Assertions 部分列出了通过读取 .claude/agents/technical-director.md 的 frontmatter 即可自动核验的四项检查description:字段存在且为领域专用引用 architecture、feasibility、ADR而非泛化描述——实际 frontmatter 中确实写明owns all high-level technical decisions including engine architecture, technology choices, performance strategy, and technical risk management且tools配置为Read, Glob, Grep, Write, Edit, Bash, WebSearch。allowed-tools:列表允许 Read 用于架构文档Bash 仅在需要技术检查时使用——与 frontmatter 工具集一致。模型层级为 Opus规格按协调规则要求directors with gate synthesis Opus。Agent 定义不声称拥有游戏设计或创意方向决策权。这组断言的特点是全部可离线核验不依赖夹具fixture与 CCGS Skill Testing Framework/skills/gate/gate-check.md 中由/skill-test static自动核验的机制对应是最低成本的第一道质量闸门。四、五个行为测试用例详解规格的核心是五个场景化用例每个用例给出 Scenario场景、Expected期望行为、Assertions断言清单可执行后给出 PASS / FAIL / PARTIAL 结论。Case 1域内请求——输出格式正确TD-ARCHITECTURE场景提交Combat System架构文档采用分层设计input layer → game logic layer → presentation layer各层接口清晰请求标记TD-ARCHITECTURE。期望返回TD-ARCHITECTURE: APPROVE理由确认系统边界分离正确、接口定义良好。关键断言判定词严格取 APPROVE / CONCERNS / REJECT 之一判定词以TD-ARCHITECTURE: APPROVE令牌格式出现而非散落在段落中的散文式结论理由必须具体引用分层结构与接口定义拒绝泛泛的架构建议输出不越出技术范围——不评论机制是否有乐趣或是否符合创意愿景。这与 Agent 定义中的 Gate Verdict Format 完全呼应[GATE-ID]: APPROVE必须独占一行、位于回复首行calling skill reads the first line for the verdict token即下游技能靠解析首行令牌做自动化判定所以格式即协议。Case 2域外请求——重定向或升级对话脚本评审场景Writer 请求技术总监评审并批准开场过场动画的对话脚本。期望Agent 拒绝评价对话质量重定向到 narrative-director。关键断言不对对话内容或结构做任何有约束力的决定明确指名narrative-director为正确处理者对应真实 Agent .claude/agents/narrative-director.md可以提示影响对话的技术约束如本地化字符串长度限制、数据格式但所有内容决策一律让渡。该用例验证的是协作协议中的重定向能力Agent 识别跨域请求 → 指名正确归属 → 不静默处理杜绝顺手把别家活干了的越权。Case 3门禁判定——正确词汇与算法复杂度引用TD-FEASIBILITY场景一个多人机制要求每帧对所有活跃实体做 raycast 视线检测在目标玩家规模大区域内 1000 实体下为每帧 O(n²) 复杂度。请求标记TD-FEASIBILITY。期望返回TD-FEASIBILITY: CONCERNS并具体引用 O(n²) 复杂度与在目标帧率下不可行的实体数量阈值。关键断言判定词严格为三选一令牌格式TD-FEASIBILITY: CONCERNS理由包含具体的算法复杂度关切与实体数量阈值不能只说性能可能有问题至少提出一种替代方案如空间分区 spatial partitioning、兴趣管理 interest management但不强制指定采用哪一个。这是技术可行性门禁最典型的形态既要有量化依据复杂度 数量阈值又要保持咨询者身份给选项不给命令与 Agent 定义中present 2-3 strategic options…the user chooses的协作哲学一致。Case 4冲突升级——正确的上级仲裁者场景game-designer 想为每个背包物品加实时物理模拟数百物品同屏。技术总监评估为技术代价高昂、提议简化game-designer 反对认为这对游戏手感至关重要。期望技术总监清楚陈述技术代价与约束提出能近似还原手感的替代实现方案但把这个代价值不值得的最终设计优先级判断明确让渡给 creative-director——作为玩家体验权衡的仲裁者。关键断言技术关切要具体性能预算、估算代价至少提一个降低成本且保留意图的替代方案明确让渡值不值得付这个代价给 creative-director不单方面砍功能不声称有权否决 game-designer 的设计意图。该用例对应的正是 Agent 定义中的委托/升级映射技术总监是 cross-system technical conflict 的 escalation target但设计优先级冲突的最终仲裁者是 creative-director对应 .claude/agents/creative-director.md。注意与模板中 Case 4escalates to the shared parent (or creative-director / technical-director)的通用表述相比本规格把上级明确固定为 creative-director更精确。Case 5上下文透传——使用给定上下文而非泛泛而谈场景Agent 收到包含目标平台约束的门禁上下文块移动端、60fps 目标、2GB 内存上限、不支持 compute shader。提案架构包含 GPU-driven rendering pipeline。期望评估引用给定硬件约束识别 compute shader 依赖与平台约束不兼容返回带具体引证的 CONCERNS 或 REJECT。关键断言引用具体平台约束mobile、2GB RAM、no compute shaders不脱离给定约束给出泛化性能建议正确识别与平台约束冲突的架构组件判定理由绑定给定上下文而非套话式警告。该用例与模板 Case 5Agent uses provided context rather than re-asking for it一致验证的是门禁裁决的情境化质量——这是区分真门禁与模板复读机的关键测试。五、协议合规清单与门禁生态Protocol Compliance 将上述行为浓缩为五条全局契约任何一次调用都应满足仅使用 APPROVE / CONCERNS / REJECT 判定词汇不越出声明的技术领域设计优先级冲突让渡给 creative-director输出使用门禁 ID如TD-FEASIBILITY: CONCERNS而非散文式结论不做有约束力的游戏设计或创意方向决定。将 technical-director 放回门禁生态看其角色远不止单个 Agent阶段门禁CCGS Skill Testing Framework/skills/gate/gate-check.md 的 Case 5 规定full评审模式下/gate-check会并行唤起四位总监的 PHASE-GATE 判定CD-PHASE-GATE、TD-PHASE-GATE、PR-PHASE-GATE、AD-PHASE-GATE任一总监返回 CONCERNS 则整体门禁至少为 CONCERNSsolo模式则输出[TD-PHASE-GATE] skipped — Solo mode后仅凭产物/质量检查判定。这解释了本规格 Coverage Notes 中TD-PHASE-GATE 涉及多子门禁综合、暂缓覆盖的原因——它是更上层技能的集成行为。ADR 审批CCGS Skill Testing Framework/skills/authoring/architecture-decision.md 规定在full模式下 ADR 草稿完成后TD-ADR 与 LP-FEASIBILITY 两门禁并行唤起TD-ADR 返回 CONCERNS 时 ADR 状态保持 Proposed 而非 Accepted。这正好对应本规格 Coverage Notes 中TD-ADR 尚未覆盖的缺口——技能规格已定义其行为Agent 规格尚未补齐对应用例。输出格式Agent 定义要求架构决策按 ADR 格式输出Title / Status / Context / Decision / Consequences / Performance Implications / Alternatives ConsideredStatus 取值 Proposed / Accepted / Deprecated / Superseded——这是门禁判定之外技术总监产出物的事实标准。六、覆盖缺口已知未测领域与演进方向Coverage Notes 诚实列出了规格尚未覆盖的四个区域也是后续补充测试用例的清单TD-ADR 未覆盖应在/architecture-decision技能产出 ADR 文档后补充专门用例如上文所述技能侧 CCGS Skill Testing Framework/skills/authoring/architecture-decision.md 已定义 TD-ADR 行为Agent 侧尚未同步。TD-ENGINE-RISK 未覆盖针对特定引擎版本的评估如 Godot 4.6 截断后 API推迟到 engine-specialist 集成测试对应引擎参考文档 docs/engine-reference/godot/VERSION.md 等版本资料。TD-PHASE-GATE 未覆盖涉及多个子门禁结果综合的完整技术阶段推进判定属于集成级行为。多域架构评审未覆盖同时触及 TD-ARCHITECTURE 与 TD-ENGINE-RISK 的交叉场景。七、如何在框架中运行与演进本规格查看 Agent 定义.claude/agents/technical-director.md 是运行时行为本体本规格文档 CCGS Skill Testing Framework/agents/directors/technical-director.md 是行为契约。执行行为测试在仓库根目录对 Claude 发起/skill-test spec technical-director框架将按本文档的断言逐条评估/skill-test audit可查看全量 agents skills 的 has-spec / last tested / result 覆盖总览见 CCGS Skill Testing Framework/README.md。补充用例按 CCGS Skill Testing Framework/templates/agent-test-spec.md 模板新增用例并在 CCGS Skill Testing Framework/catalog.yaml 中登记随后运行/skill-test spec technical-director校验。约束提醒本目录自包含且可选可整体移除而不影响.claude/依赖CCGS Skill Testing Framework/README.md 中有明确说明。结语technical-director 的测试规格是 CCGS给 Agent 写行为契约理念的典型样本用TD-系列门禁 ID 固定输出协议、用领域边界约束职权、用五类用例覆盖域内正确输出、域外重定向、量化判定、冲突升级、上下文透传五种核心行为再以覆盖缺口清单指引后续演进。对于任何试图把 LLM Agent 引入高风险技术决策流程的团队这套规格-断言-用例-合规-缺口的结构本身就是一份可复用的质量保障模板。【免费下载链接】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），仅供参考