这是什么
一个几乎不含程序、却含有大量指令的仓库。它把一次 Claude Code 会话变成一间形似游戏工作室的东西：四十九个 agent 定义，覆盖创意与技术总监、制作、美术、音频、叙事、工程、QA、发布、安全与长线运营，另有面向 Godot、Unity、Unreal 的引擎专家；约七十个技能；十四个会在提交、推送、素材与技能变更处设卡的 shell 钩子；十三个规则文件；以及约四十份文档模板，从立项简报到复盘报告。它以 clone 或 Claude Code 插件两种方式安装。
谁做的四十一提交全出自他一人之手，每一次都挂在已关联账号上，GitHub 也只把他列为贡献者。而 pull request 队列里躺着另外几个人的提交，发布说明也按 handle 向他们致谢——所以贡献者图和队列里的流量，各自朝相反方向低估了对方。
制作过程
8 个阶段- 01
两万五千个星，四十一次提交
这个比例首先值得记下。25,530 星、3,641 fork、184 watcher，而提交数是 41。对一个应用来说这荒唐；在这里它是准确的，因为产物不是代码。这 41 次提交里有 39 次带一条写明模型的共同作者尾注——95%，本档案见过的最高比例，对比 gate4agent 的 71%、CodeGraph 的 66%——其中 Claude Sonnet 4.6 占三十次，Opus 4.6 六次，Opus 5 与 Opus 5.5 各一次。七个月里八个 release，名字读起来像一句变更说明而不是版本号：第一次公开发布，然后是上下文韧性与系统拆解，再是设计系统与地图系统那一版，接着是插件时期的几版，最后一版说的是「默认路径端到端可用了」。
- 02
一张写成了文件的工作室组织图
这个仓库是一个有形状的
.claude/目录。四十九个 agent 定义，每个四到十八 KB，按角色而不是按功能命名：创意总监、技术总监、制作人、美术总监、音频总监、叙事总监、主程，以及引擎、玩法、网络、工具与 UI 程序员，QA 主管与测试，发布经理，安全工程师，长线运营设计，本地化主管，经济系统设计，关卡设计，世界观构建，编剧，音效设计，性能分析，原型师，社区经理，无障碍专家，分析工程师。引擎专长还继续细分——五位 Godot 专家（含 GDScript、C#、GDExtension 各一）、五位 Unity 专家（含 DOTS、Addressables、着色器）、四位 Unreal 专家，外加蓝图、GAS、网络同步与 UMG 各自的 agent。它们周围是十三个规则文件、十四个 shell 钩子、十个脚本、一份 22 KB 的工作流目录，以及约四十份文档模板——从立项简报、路演文档，到游戏设计文档、美术圣经、音效圣经、经济模型、难度曲线、UX 规格与玩家旅程，再到发布清单、测试计划与复盘报告。单篇最大的文档是一份 138 KB 的效果映射表。 - 03
数字一直在漂，而 pull request 就是在处理这件事
这个体量的配置有一个「清单问题」，而追踪器对此异常诚实。有一条 PR 修正 README——它宣称有四十一个模板，而目录里只有四十个——并在同一口气里记下同一张表里的其它计数（agent 49、技能 73、钩子 12、规则 11）都核对过、是准确的。另一条把还没跟上最新 agent 的两处文档改掉：四十八个子 agent 改成四十九，「六十八个斜杠命令」改成七十二，并把验证过程写成产生它的命令——列一下 agent 文件数一数、列一下技能目录数一数。还有一条发现 agent 测试规格与模型等级表已经和 agent 文件里实际声明的东西脱节，并列出一张分歧表。问题不在于数字错了，而在于「由散文构成的部分」不断需要和「由文件构成的部分」对账，而这些 PR 在公开场合完成对账。分歧此刻仍然挂在顶上：仓库简介写七十二个 workflow skills，README 写七十四。
- 04
六十六个文件里的一行，把整套东西弄坏了
历史里最锋利的一次事故，是一个发布在两天后不得不被修复。1.1.0 给六十六个技能加了一行配置——一段在渲染时 source 辅助脚本并解析配置键的 shell 替换。而 Claude Code 会在技能渲染之前对每个注入命令做权限检查，在非 auto 模式下这一行会因为「包含展开」而检查失败，且没有任何授权能批准它。后果并不微妙：六十六个技能全部在做任何事之前静默中止，某种模式下那三十一个没有 shell 授权的从根目录也失败，而游戏设计师与创意总监两个 agent 根本无法启动，因为它们会预加载这些技能。1.1.1 这一版的名字就是为这次修复起的。教训写在 PR 里而不是暗示出来：在别人的扩展点上做东西，就意味着那套权限模型是你架构的一部分，而一个在某种模式下安全的机制，在另一种模式下可能根本不可用。
- 05
能拒绝一次提交的钩子
十四个 shell 钩子围绕会话运行而不是在会话里——会话开始一个、结束一个，上下文压缩前后各一个，两个记录 agent 活动，一个检测缺口，一个校验素材，一个校验技能变更，还有两个把住 git 操作：一个提交校验器、一个推送校验器。它们的体积就是线索：提交校验器是三万八千字节的 shell，技能共用的 YAML 助手是六万八千字节，素材校验器八 KB，推送校验器十 KB。此外还有用于架构决策图、产物检查、设计文档结构、项目一致性、评审回执、评审范围、会话状态轮换与故事状态的脚本，以及一个配置格式迁移脚本。一份 pull request 清单告诉贡献者钩子对他们有什么要求：用 POSIX 的 grep，在既没有 jq 也没有 python 时优雅失败，不硬编码路径，不假设平台。
- 06
两次会话，一次 high，一次 xhigh
有一位贡献者用两句话描述了自己的做法：这次升级用了两次模型会话，第一次在 high 档产出初版，第二次在 xhigh 档做评审并磨平了几处不一致。把推理档位当作评审协议是件小事，但它是对这类项目共同面对的那个问题的刻意回答——同一个模型既写又批，除非你改变点什么。后来一条新增素材生成技能的贡献，同样精确地写明了它的约束：助手会去校验实时的模型目录而不是假定它，从不重试生成请求，对轮询设上界，把所有产出留在项目目录内，并且在每一个要花钱的请求之前先问一次。一个把工作室自动化掉的仓库，对「让自动化花什么钱」反而格外谨慎。
- 07
打包方式变了，而指令没有动
插件时期那一版是发布之后最具架构性的一次改动。插件清单指现有的 agent、技能和钩子目录，而不是把它们搬走，所以 clone 的用法照旧；一个 marketplace 文件把整套东西以一个短名字发布出去。真正有意思的是插件装不了的那部分：一个项目需要自己的
CLAUDE.md、自己的规则、自己的文档树和一份引擎参考。与其把它留成升级冲突，维护者加了一个初始化技能来搭出项目这一侧，而 PR 直说：这移除了此前那份升级指南存在的理由——升级时的合并冲突。一份以插件形式分发的配置，只有把「属于工具的东西」和「属于项目的东西」分开，才能获得干净的升级路径。 - 08
贡献者列表里一个名字，队列里好几个
56 个 issue 开着。仓库页面上列着两个贡献者：维护者，以及 Claude——共同作者尾注替一个模型挣到了贡献者列表上的位置（而 API 的 contributors 端点只返回人那一个）。与此同时，pull request 队列里躺着另外几个人的提交，发布说明也按 handle 向他们致谢，也就是说工作是从外面来的，却落在维护者的名下。这个仓库里一些最仔细的文字在那个队列里而不在代码里：那一行阻塞发布的 shell、那次漂移审计、那份把「一次贡献必须证明什么」写死的清单。这就是一个文档重于代码的开源项目的诚实形状——提案多于合并、表面多于程序，以及一个唯一有权批准任何东西的维护者。