Claude Code Game Studios catalog.yaml：追踪全部72个技能测试状态的主注册表
【免费下载链接】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 Studios把 Claude Code 变成一家拥有 49 个 AI 智能体、72 个工作流技能的虚拟游戏工作室。其中 catalog.yaml 是整个技能测试框架的"主注册表"：它集中登记了全部 72 个技能与 49 个智能体的规格文件路径、所属类别与最近一次测试结果，让你一张表就能看清整个"AI 工作室"的质量状况。
catalog.yaml 是什么？为什么需要它？
CCGS Skill Testing Framework 是项目内置的"质量保障层"——它测试的不是游戏本身，而是这些技能和智能体是否按规范工作。
想象一个现实中的游戏工作室：每个岗位都有职责说明书、每次交付都有验收记录。catalog.yaml就是这个"验收台账"：
| 维度 | catalog.yaml 承担的职责 |
|---|---|
| 登记 | 每个技能/智能体一条记录：名称、规格文件路径、所属类别 |
| 分级 | 技能按优先级分为 critical / high / medium / low 四档 |
| 追踪 | 记录三种测试模式各自的"最近一次运行时间 + 结果" |
对新手来说，理解它只需记住一句话：先查 catalog，再跑测试。框架的智能体说明 CLAUDE.md 明确要求：执行任何测试命令前，都先读取 catalog.yaml 获取该技能的spec:路径和category:，而不是去猜文件位置。
文件结构：skills 与 agents 两大区块
打开 catalog.yaml，整个文件由顶层版本号和两大区块构成：
skills:区块— 登记全部 72 个技能，按优先级从高到低排列agents:区块— 登记 49 个智能体，按"层级"分组（导演 → 组长 → 专家 → 引擎专家 → 运营）
每个技能记录包含固定的 7 个字段，以gate-check为例：
| 字段 | 含义 |
|---|---|
name | 技能名，对应斜杠命令，如gate-check |
spec | 行为规格文件路径（权威路径，测试时必须读它） |
last_static/last_static_result | 最近一次结构检查的时间与结果 |
last_spec/last_spec_result | 最近一次行为规格测试的时间与结果 |
last_category/last_category_result | 最近一次类别评分的时间与结果 |
priority | 优先级：critical / high / medium / low |
category | 类别：gate、review、pipeline、team 等 |
智能体记录更精简——只有name、spec、last_spec(_result)和category，因为智能体只做规格测试，不做结构检查。
优先级四档划分：先测哪些技能？
catalog 并非简单罗列，而是按"失效影响"排序。测试资源有限时，从上往下测即可：
| 优先级 | 定位 | 代表技能 |
|---|---|---|
| 🔴critical | 控制阶段流转的"门禁"技能，出错最致命 | gate-check、design-review、story-readiness、story-done、review-all-gdds、architecture-review |
| 🟠high | 流水线关键技能，串联设计与开发 | create-epics、create-stories、dev-story、map-systems、consistency-check |
| 🟡medium | 团队与冲刺管理 | sprint-plan、sprint-status、各team-*技能 |
| ⚪low | 分析、报告与工具类 | start、help、brainstorm、hotfix、balance-check等 |
类别（category）则决定了评分标准：框架为 gate、review、authoring、readiness、pipeline、analysis、team、sprint、utility 九大类各定义了 4~5 条 PASS/FAIL 指标，全部写在 quality-rubric.md 中。例如 gate 类要求"绝不在未经用户确认时写入阶段文件"，review 类要求"只读、使用固定判定词汇"。
三种测试模式与 catalog 字段的对应关系
skill-test 技能提供四种模式，其中三种会回写 catalog 的追踪字段：
| 命令 | 检查内容 | 回写字段 |
|---|---|---|
/skill-test static [name] | 7 项结构检查（frontmatter 字段、阶段标题、判定关键词等） | last_static（可经/skill-improve更新） |
/skill-test spec [name] | 对照规格文件的测试用例逐条评估行为 | last_spec、last_spec_result |
/skill-test category [name] | 按类别评分表打分 | last_category、last_category_result |
/skill-test audit | 输出全部技能/智能体的覆盖总表 | 只读，用于体检 |
测试完成后的建议更新动作由 README.md 规定：spec测试后主动提示更新last_spec字段，category测试后提示更新last_category字段——catalog 因此始终反映"最新已知状态"，而不是某次历史快照。
实战：如何用 catalog 给一个技能做完整体检
以 critical 级的gate-check为例，完整流程四步：
- 查注册表— 打开 catalog.yaml，确认
gate-check的priority: critical、category: gate，并记下spec字段指向的规格文件 - 跑结构检查—
/skill-test static gate-check，看 7 项结构检查是否全部 PASS - 跑规格测试—
/skill-test spec gate-check，让 AI 对照规格文件逐用例判定，最后更新last_spec字段 - 修不好？走改进循环—
/skill-improve gate-check会自动执行"测试 → 诊断 → 提出修复 → 重写 → 复测 → 保留或回滚"的完整闭环，并顺带更新last_static字段
新增技能时，catalog 也是登记入口：按 templates/skill-test-spec.md 写好规格文件后，在 catalog 中补一条记录并指向它，整个测试体系才算"收编"了这个新技能。
新手常见疑问 FAQ
📌 删掉这个文件夹会影响主项目吗？不会。测试框架是完全自包含的，主框架的任何部分都不依赖它。删除后/skill-test会报告 catalog.yaml 缺失，并引导你重新初始化——这是设计上有意保留的降级路径。
📌 规格测试失败，说明技能一定错了吗？不一定。框架明确提示：规格文件描述的是"当前行为"而非"理想行为"，可能连 bug 一起被记录在内。正确姿势是先修复技能，再更新规格，最后重测。
📌 72 个技能和 49 个智能体都登记了吗？是的。catalog 的skills:与agents:区块即全量清单，/skill-test audit输出的覆盖表正是基于它生成，可快速发现"有技能、无规格"的空白。
总结
catalog.yaml 用一份 YAML 就解决了 AI 工作流项目里最容易被忽视的问题——质量状态的可追溯性：
- ✅ 一处登记 72 技能 + 49 智能体的规格路径与类别
- ✅ 四档优先级，让测试资源投向最关键的"门禁"技能
- ✅ 三类测试字段持续记录"最近一次结果"，质量趋势一目了然
- ✅ 与
/skill-test、/skill-improve无缝联动，形成"测完即登记"的闭环
配合 quality-rubric.md 的类别评分表与 templates/ 下的规格模板，这套注册表就是 Claude Code Game Studios 能像真实工作室一样稳定运转的底层账本。
【免费下载链接】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），仅供参考
