Claude Code Game Studios 的 /map-systems：从游戏概念到系统索引的强制门禁流水线实战指南
【免费下载链接】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（CCGS）中pipeline类别的高优先级技能/map-systems展开，解析它如何把已获批的游戏概念（game concept）与设计支柱（pillars）分解为一份结构化的系统索引（systems index）：枚举显式与隐式系统、绘制系统间依赖、分配优先级层级（MVP / Vertical Slice / Alpha / Full Vision），并按 Foundation → Core → Feature → Presentation 的分层设计顺序组织输出，最终写入design/systems-index.md。读者读完本文后将掌握：该技能的输入输出契约、三档评审模式（full / lean / solo）下的导演门禁行为、五种行为测试用例及其断言口径，以及它在 CCGS 七阶段流水线中与上下游技能（/brainstorm、/design-system、/review-all-gdds）的衔接方式。
本文以 map-systems.md 技能测试规格 为骨架，仓库中其余文档（如 质量评分规则、流程指南、创意总监与技术总监规格）仅用于深化佐证。
一、技能定位：概念获批与 GDD 编写之间的强制门禁
1.1 它是谁、做什么
/map-systems是 CCGS 流水线中位于「游戏概念获批」与「逐系统 GDD 编写」之间的强制门禁技能（mandatory gate）。它不产生任何玩法代码，也不直接书写设计细节，而是产出一份系统级蓝图。其核心职责拆解如下（依据 map-systems.md）：
| 职责 | 说明 |
|---|---|
| 读取上游输入 | 已获批的design/gdd/game-concept.md（含 Core Mechanics 与 MVP Definition 章节）与design/gdd/game-pillars.md（至少 1 条支柱） |
| 枚举系统 | 同时识别显式系统（概念中明确写出的机制）与隐式系统（概念隐含但未言明的支撑机制） |
| 映射依赖 | 在系统之间绘制依赖边，并在映射阶段执行循环依赖检测（如 System A 依赖 System B、System B 又依赖 System A） |
| 分配优先级 | 按 MVP / Vertical Slice / Alpha / Full Vision 四档分层级 |
| 组织分层顺序 | 按 Foundation → Core → Feature → Presentation 四层设计顺序排布 |
| 写出产物 | 经用户批准后写入design/systems-index.md |
该技能在 catalog.yaml 中被登记为category: pipeline、priority: high，与create-epics、create-stories、dev-story、create-control-manifest、propagate-design-change同属流水线类技能。
1.2 在七阶段流水线中的位置
流程指南 展示了该技能的上下游链路：
- 上游（Phase 1 概念阶段）：
/brainstorm产出game-concept.md→/design-review校验概念 →/setup-engine固定引擎 → 进入/map-systems生成systems-index.md（含全部系统、依赖与优先级层级）。 - 下游（Phase 2 系统设计阶段）：
/map-systems next从索引中挑出最高优先级且尚未设计的系统，交接给/design-system逐节编写 GDD，随后经/design-review校验 8 个必需章节，最后用/review-all-gdds做跨 GDD 一致性与设计理论审查。
换句话说，systems-index.md是所有下游 GDD 的「设计任务清单」，缺少它就无从谈起「按依赖顺序设计系统」。
二、三档评审模式下的导演门禁行为
CCGS 全框架通过production/session-state/review-mode.txt控制评审强度（在/start时设定，或用--review <mode>临时覆盖）。/map-systems的门禁行为完全随模式切换：
| 评审模式 | CD-SYSTEMS（创意总监） | TD-SYSTEM-BOUNDARY（技术总监） | 说明 |
|---|---|---|---|
full | 并行触发 | 并行触发 | 两份门禁在系统分解草稿完成之后、design/systems-index.md写入之前并行（parallel）发起，二者均返回 APPROVED 才继续 |
lean | 跳过，输出注明 | 跳过，输出注明 | 输出中必须包含 "CD-SYSTEMS skipped — lean mode" 与 "TD-SYSTEM-BOUNDARY skipped — lean mode" 两条说明 |
solo | 跳过，输出注明 | 跳过，输出注明 | 输出中注明 "solo mode"，其余行为与 lean 模式对本技能而言一致 |
两条门禁对应的导演 agent 分别是：
- CD-SYSTEMS：由 creative-director（创意总监） 承接，属于其
Gate IDs handled列表（CD-PILLARS、CD-GDD-ALIGN、CD-SYSTEMS 等）之一，负责「系统分解反馈」这一创意域；判定词为 APPROVE / CONCERNS / REJECT。 - TD-SYSTEM-BOUNDARY：由 technical-director（技术总监） 承接，负责系统边界、技术可行性等架构域；同样采用 APPROVE / CONCERNS / REJECT 判定。
两位总监均为 Opus 模型层级的导演 agent（多文档综合、高风险的阶段门禁判定）。
为什么强调「并行」
规格文档明确断言：full 模式下两条门禁是并行spawn 而非串行。这与 质量评分规则 中团队类指标 T2（「相互独立的 Agent 应并行生成」）同源，也与 pipeline 类指标 P4（「在作用域内的门禁于 full 模式运行、lean/solo 跳过并注明」）严格对齐。
三、五种行为测试用例全解
map-systems.md作为行为规格（behavioral spec），通过五种夹具（fixture）驱动/skill-test spec map-systems验证技能行为。以下逐案展开，标注断言口径，便于读者理解「什么才算通过」。
Case 1：Happy Path —— 概念存在，识别出 5–8 个系统
夹具前提：
design/gdd/game-concept.md存在，且含 Core Mechanics 与 MVP Definition 两节；design/gdd/game-pillars.md存在，且至少定义 1 条支柱；design/systems-index.md尚不存在；production/session-state/review-mode.txt内容为full。
预期行为链：
- 读取
game-concept.md与game-pillars.md； - 识别出 5–8 个系统（显式 + 隐式）；
- 映射系统间依赖并分配分层（layers）；
- CD-SYSTEMS 与 TD-SYSTEM-BOUNDARY并行发起并均返回 APPROVED；
- 询问 "May I write
design/systems-index.md?"； - 获批后写入
systems-index.md； - 更新
production/session-state/active.md（会话状态）。
断言要点：
- 系统数量必须在5 到 8 之间——除非给出解释，否则不得少于或多于；
- 两条门禁必须并行（而非串行）；
- 两条门禁都完成之后才能发出 "May I write" 询问；
- 未经批准绝不写入
systems-index.md； - 写入后必须更新会话状态；
- 最终判定词为COMPLETE。
Case 2：失败路径 —— 找不到游戏概念
夹具前提：design/gdd/game-concept.md不存在（目录可空或缺失）。
预期行为：
- 技能尝试读取
design/gdd/game-concept.md； - 文件不存在；
- 输出明确错误信息："No game concept found. Run
/brainstormto create one, then return to/map-systems."； - 技能退出，且不创建
systems-index.md。
断言要点：错误信息必须点名缺失文件的路径；必须推荐/brainstorm作为下一步；不得创建索引文件；判定词为BLOCKED。这与 brainstorm 规格 中「概念获批后交接/map-systems」的协议闭环互为印证。
Case 3：导演门禁 —— CD-SYSTEMS 返回 CONCERNS（缺失核心系统）
夹具前提：概念存在；评审模式为full；CD-SYSTEMS 返回CONCERNS: "The [core-system] is implied by the concept but not identified"。
预期行为：
- 系统草稿完成（识别出 5–8 个系统）；
- CD-SYSTEMS 返回 CONCERNS，点名缺失的核心系统；
- TD-SYSTEM-BOUNDARY 返回 APPROVED；
- 技能把 CD-SYSTEMS 的关切如实呈现给用户；
- 询问用户：修订系统清单补上缺失系统，或按现状继续；
- 若修订：在 "May I write" 之前重新展示更新后的系统清单。
断言要点：关切必须在写入前呈现；CONCERNS 未解决时不得自动写入索引；必须给用户「修订或继续」两个选项；修订后的清单须在最终 "May I write" 前重显。
Case 4：边界情况 ——systems-index.md已存在
夹具前提：概念存在；design/systems-index.md已存在且含 N 个系统。
预期行为：
- 技能先读取既有索引并展示当前状态；
- 询问："systems-index.md already exists with [N] systems. Update with new systems, or review and revise priorities?"；
- 由用户选择动作；
- 不静默覆盖既有索引。
断言要点：必须先探测并读取既有索引；必须提供「更新 / 复核修订」选项而非自动覆盖；必须向用户展示既有系统数量；未经用户选择，不得擅自进行完整重新分解。此行为与 design-system 规格 的 retrofit 模式（检测既有 GDD 后按需更新指定章节而非整篇重写）属同一「读取优先、不静默覆写」协作原则。
Case 5：模式变体 —— lean 与 solo 模式均跳过门禁并注明
lean 模式夹具：概念存在；review-mode.txt内容为lean。
预期行为：完成系统分解草稿 → 两条门禁均跳过 → 输出注明 "CD-SYSTEMS skipped — lean mode" 与 "TD-SYSTEM-BOUNDARY skipped — lean mode" → 直接进入 "May I write" 询问 → 获批后写入索引。
solo 模式夹具：概念相同；review-mode.txt内容为solo。
预期行为：相同的分解流程，两条门禁以 "solo mode" 标注跳过，其余行为与 lean 模式一致。
断言要点：两条跳过说明必须出现在输出中（分别带模式标签）；无需门禁批准即可推进到 "May I write"；获批后照常写入。
四、静态断言、协议合规与覆盖率边界
4.1 静态断言（/skill-test static自动校验，无需夹具）
- 前置元数据字段齐全：
name、description、argument-hint、user-invocable、allowed-tools； - 至少 2 个阶段标题（phase headings）；
- 包含判定词COMPLETE与BLOCKED；
- 包含针对
systems-index.md的 "May I write" 协作协议用语； - 结尾包含下一步交接（
/design-system）； - 记录 full 模式下 CD-SYSTEMS + TD-SYSTEM-BOUNDARY 并行门禁行为。
4.2 协议合规清单
- 任何分解动作之前，先读取
game-concept.md与game-pillars.md（对应 pipeline 类指标 P5「先读后写」）； - 写入前必须问 "May I write
design/systems-index.md?"； - 未经用户批准不得写入；
- full 模式两条门禁并行；
- lean/solo 模式按门禁名与模式注明跳过；
- 结尾交接
/design-system [next-system]。
4.3 覆盖率说明（Coverage Notes）
规格文档明确标注了三处测试边界，值得工程团队注意：
- 循环依赖检测属于依赖映射阶段的一部分，但未在此独立以夹具测试；
- 优先级层级分配（MVP 启发式）作为 Case 1 协作流程的一部分被评估，而非独立测试；
next参数模式（把最高优先级未设计系统交接给/design-system）不在本测试覆盖内——它是索引创建后的便利功能，如 流程指南 所述，/map-systems next的实际价值在于按依赖顺序逐系统进入 GDD 编写。
五、与质量评分规则及模板的关系
- quality-rubric.md 的
pipeline类指标（P1–P5）为/map-systems提供了类别级验收标准：输出遵循项目模板（P1）、尊重分层与优先级字段（P2）、每个产物写入前均问 "May I write"（P3）、门禁按正确档位运行（P4）、先读后写（P5）。/skill-test category map-systems即据此评估。 - skill-test-spec.md 模板 定义了所有技能规格的统一骨架（Skill Summary / Static Assertions / Director Gate Checks / Test Cases / Protocol Compliance / Coverage Notes），
map-systems.md是该模板在 pipeline 类技能上的具体落地。 - 框架 README 提供了执行入口：
/skill-test spec map-systems（行为规格测试）、/skill-test static map-systems（静态合规检查）、/skill-test category map-systems（类别指标评估）、/skill-test audit（覆盖率总览）。
六、实战要点小结
- 门禁是强制性的：
/map-systems位于概念获批与 GDD 编写之间，full 模式下两条导演门禁并行把关，任何一条返回 CONCERNS 都会阻塞自动写入，直到用户做出修订或继续的决定。 - 5–8 个系统的数量纪律：规格将识别数量视为质量信号——过少意味着漏掉了隐式系统，过多意味着分解粒度过细；偏离时必须给出解释。
- 先读后写、May-I-write 协议：技能绝不在未经批准时写入
systems-index.md；既有索引存在时优先提供更新/复核选项，绝不静默覆盖。 - 评审模式决定门禁强度：full 走完整并行导演门禁，lean/solo 跳过并在输出中逐条注明，保证评审过程可审计。
- 下游依赖清晰：索引是 Phase 2 所有 GDD 编写的任务清单，
/map-systems next提供「按优先级逐系统进入/design-system」的便利交接。
<输出文章>
【免费下载链接】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），仅供参考
