尧图网站建设 
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导读map-systems是 Claude Code Game StudiosCCGS概念 → 系统 → GDD → 实现流水线中的核心枢纽技能它接收/brainstorm产出的游戏概念文档通过七阶段协作流程将概念拆解为一个个可独立设计的游戏系统映射系统间依赖关系按里程碑分配优先级并最终生成一份可长期维护的systems-index.md系统索引。读完本文你将掌握 CCGS 中系统拆解这一环节的完整方法论——包括显式/隐式系统识别模式、依赖分层排序、循环依赖检测、里程碑优先级分配、三档导演门禁review mode机制以及如何通过/map-systems next让设计流水线自动推进到下一个最高优先级系统。1. 技能定位连接概念与 GDD 的中间层在 CCGS 的协作设计流水线中map-systems处于承上启下的位置上游/brainstorm产出design/gdd/game-concept.md游戏概念文档与design/gdd/game-pillars.md游戏支柱文档本体/map-systems把概念拆解为系统清单、依赖图和优先级排序写入design/gdd/systems-index.md下游/design-system依据系统索引逐个撰写系统 GDD详见 .claude/skills/design-system/SKILL.md。技能本身的 frontmatter 定义如下见 .claude/skills/map-systems/SKILL.mdname: map-systems description: Decompose a game concept into individual systems, map dependencies, prioritize design order, and create the systems index. argument-hint: [next | system-name] [--review full|lean|solo] user-invocable: true allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, TodoWrite, Task从中可以看出该技能的三个设计特征用户可主动调用user-invocable: true且参数可选全程协作AskUserQuestion被列为核心工具技能在每个决策点都要征求用户意见而非静默生成可跨会话恢复TodoWrite与production/session-state/active.md配合保证长流程中断后能无缝续跑。CCGS 根级 CLAUDE.md 将整个项目的协作基调定义为 User-driven collaboration, not autonomous executionmap-systems正是这一原则的典型执行者。2. 调用方式与参数解析/map-systems支持两种运行模式见 .claude/skills/map-systems/SKILL.md Parse Arguments 一节调用形式行为/map-systems无参数执行完整的系统拆解工作流Phase 1–5创建或更新系统索引/map-systems next从索引中挑选优先级最高且尚未设计的系统交接给/design-system即 Phase 6/map-systems [system-name]直接指定要设计的系统名进入 Phase 6 交接流程2.1 评审模式Review Mode解析技能在每次运行时只解析一次评审模式供本次运行所有导演门禁共用优先级如下若调用时显式传入--review [full|lean|solo]则使用该值否则读取production/review-mode.txt中的值否则默认lean。这一解析模式与 .claude/docs/director-gates.md 中定义的全局门禁机制完全一致。该文档规定production/review-mode.txt是在/start时一次性设置的全局配置文件内只放一个词full、lean或solo而--review参数则只对本次运行生效。三种模式的含义差异影响门禁是否执行模式行为适用场景full所有门禁激活每个工作流步骤都接受导演评审团队协作、学习型用户、希望每个步骤都有导演反馈lean仅 PHASE-GATE/gate-check生效逐技能门禁跳过默认——独立开发者与小团队导演只在里程碑节点介入solo所有导演门禁全部跳过Game Jam、原型开发、追求最高速度3. Phase 1读取概念前置上下文系统拆解必须有原材料因此 Phase 1 强制读取游戏概念文档必读项design/gdd/game-concept.md。如果该文件缺失技能必须用清晰的消息直接失败No game concept found atdesign/gdd/game-concept.md. Run/brainstormfirst to create one, then come back to decompose it into systems.可选项存在即读design/gdd/game-pillars.md——游戏支柱会约束优先级与范围判断design/gdd/systems-index.md——若已存在则从上次断点续写更新而非推倒重建用 Glob 扫描design/gdd/*.md——检查哪些系统 GDD 已经存在。若系统索引已存在技能需先读取并展示当前状态然后用AskUserQuestion询问用户The systems index already exists with [N] systems ([M] designed, [K] not started). What would you like to do?选项为Update the index with new systems更新索引、Design the next undesigned system设计下一个未设计系统、Review and revise priorities评审并修订优先级。这一步保证了技能的可恢复性与幂等性——重复调用不会丢失已有工作。4. Phase 2系统枚举协作核心系统枚举是整个技能的创意核心它要求人类判断参与因为概念文档几乎不会显式罗列每一个系统。该阶段分三步4.1 Step 2a提取显式系统扫描概念文档中直接提到的系统与机制重点看四个章节Core Mechanics 章节最显式Core Loop 章节隐含每个循环层级由哪些系统驱动Technical Considerations 章节网络、程序化生成等MVP Definition 章节必需功能 必需系统。4.2 Step 2b识别隐式系统对每个显式系统找出它隐含的隐藏系统。游戏的系统数量永远多于概念文档写出来的数量。技能内置了七类典型推理模式概念提到隐含系统Inventory背包物品数据库、装备槽、重量/容量规则、背包 UI、物品序列化用于存档/读档Combat战斗伤害计算、生命系统、命中判定、状态效果、敌人 AI、战斗 UI血条、伤害数字、死亡/重生Open world开放世界流式加载/区块划分、LOD 系统、快速旅行、地图/小地图、兴趣点追踪、世界状态持久化Multiplayer多人网络层、大厅/匹配、状态同步、反作弊、网络 UIping、玩家列表Crafting制作配方数据库、材料采集、制作 UI、成功/失败机制、配方发现/学习Dialogue对话对话树系统、对话 UI、选择追踪、NPC 状态管理、本地化钩子Progression成长XP 系统、升级机制、技能树、解锁追踪、成长 UI、成长存档数据技能要求在对话文本中解释每个隐式系统为何必要配示例让用户理解推理链而非只看到结论。4.3 Step 2c用户审核按类别组织枚举结果为每个系统展示名称、类别、一句话描述、来源显式/隐式。随后用AskUserQuestion收集三类反馈Are there systems missing from this list?是否有遗漏Should any of these be combined or split?是否有需要合并或拆分Are there systems listed that this game does NOT need?是否有本游戏不需要的迭代直到用户批准枚举结果才进入下一阶段。5. Phase 3依赖映射协作核心一个系统依赖另一个系统指的是没有后者前者就无法运作。5.1 Step 3a依赖启发式三类依赖判断依据输入/输出依赖系统 A 产出的数据是系统 B 的输入结构性依赖系统 A 提供了系统 B 要插入的框架UI 依赖每个玩法系统都有对应的 UI 系统依赖它但 UI 在玩法系统之后设计。5.2 Step 3b按依赖序分层将所有系统排成五层从上到下设计、构建Foundation地基层零依赖的系统最先设计、最先构建Core核心层只依赖地基层系统的系统Feature功能层依赖核心层系统的系统Presentation表现层包裹玩法系统的 UI 与反馈系统Polish打磨层元系统、教程、数据分析、无障碍。这一分层结构直接对应系统索引模板中 .claude/docs/templates/systems-index.md 的 Dependency Map 章节——模板要求按 Foundation / Core / Feature / Presentation / Polish 五层组织依赖图每层列出系统及其放置理由。5.3 Step 3c检测循环依赖检查依赖图中是否存在环。若发现循环依赖向用户高亮提出解决方案接口抽象interface abstraction、同时设计simultaneous design、或通过定义两个系统间的契约来打破循环。5.4 Step 3d呈现给用户 技术总监门禁以分层列表展示依赖图并高亮三类风险循环依赖瓶颈系统很多系统依赖它——高风险无依赖者的叶节点系统低风险可晚设计。用AskUserQuestion询问Does this dependency ordering look right? Any dependencies Im missing or that should be removed?评审模式检查在 spawn TD-SYSTEM-BOUNDARY 之前执行solo→ 跳过记录 TD-SYSTEM-BOUNDARY skipped — Solo mode.直接进入优先级分配lean→ 跳过非 PHASE-GATE记录 TD-SYSTEM-BOUNDARY skipped — Lean mode.直接进入优先级分配full→ 正常 spawn。依赖映射获得批准后通过 Task 工具 spawntechnical-director使用 TD-SYSTEM-BOUNDARY 门禁定义于 .claude/docs/director-gates.md然后才能进入优先级分配。需要传递给门禁的上下文包括依赖图摘要、分层分配、瓶颈系统清单、循环依赖解决方案。根据 .claude/docs/director-gates.md 中 TD-SYSTEM-BOUNDARY 门禁的定义技术总监从架构视角审查系统分解重点检查系统边界是否干净——每个系统是否拥有独立关注点、重叠最小是否存在 God Object 风险系统承担过多职责依赖排序是否会造成实现时序问题边界划分是否隐含共享状态问题导致实现时紧耦合是否存在反转依赖地基层系统实际依赖功能层系统。门禁判定结果处理若REJECT需与用户一起修订系统边界后再进入优先级分配若CONCERNS将问题内联记录到系统索引中并继续。6. Phase 4优先级分配协作核心6.1 Step 4a基于概念的自动分配按里程碑需求用以下启发式进行初始分配优先级档位判定标准MVP概念文档 Required for MVP 章节提到的系统加上它们的 Foundation 层依赖Vertical Slice某个区域内完整体验所需的系统Alpha其余所有玩法系统Full Vision打磨、元系统、锦上添花类系统这一档位体系与系统索引模板的 Priority Tiers 章节一致见 .claude/docs/templates/systems-index.mdMVP 用于验证是否好玩Vertical Slice 用于演示完整体验Alpha 是完整机制范围 占位内容Full Vision 则是打磨与补全。6.2 Step 4b用户审核与Why列指导用表格展示各系统的优先级分配解释每个档位的放置理由然后用AskUserQuestion询问Do these priority assignments match your vision? Which systems should be higher or lower priority?技能特别强调Why 列的撰写指导解释放置理由时要混合技术必要性与玩家体验理由不能只写纯技术理由如战斗需要伤害数学而要关联玩家体验。技能给出的优质示例Required for the core loop — without it, placement decisions have no consequence (Pillar 2: Placement is the Puzzle)核心循环必需——没有它放置决策就没有后果对应支柱 2放置即谜题Ballistas punch-through identity is established here — this stat definition is what makes it feel different from Archer弩炮的穿透身份在此确立——这个属性定义正是它与弓手手感差异的来源Foundation for all economy decisions — players must understand upgrade costs to make meaningful placement choices所有经济决策的基础——玩家必须理解升级成本才能做出有意义的放置选择。当系统直接塑造玩家体验时单纯的技术必要性X 依赖 Y是不充分的理由。评审模式检查在 spawn PR-SCOPE 之前执行solo/lean跳过并记录full正常 spawn。优先级批准后通过 Task spawnproducer使用 PR-SCOPE 门禁。需要传递的上下文包括各里程碑档位的系统总数、每档的估算实现工作量系统数 × 平均复杂度、团队规模、声明的项目时间线。PR-SCOPE 门禁见 .claude/docs/director-gates.md返回三种判定REALISTIC范围与产能匹配、OPTIMISTIC建议具体调整、UNREALISTIC阻塞——时间线或 MVP 必须修订。若判定为 UNREALISTIC需要先提供修订优先级档位分配的选择再写索引若为 CONCERNS记录后继续。6.3 Step 4c确定设计顺序将依赖排序与优先级档位结合产出最终设计顺序MVP Foundation 系统第一MVP Core 系统第二MVP Feature 系统第三Vertical Slice 的 Foundation/Core 系统……依此类推。这就是团队撰写 GDD 的顺序。该顺序在 .claude/docs/templates/systems-index.md 中由 Recommended Design Order 表格承载表格列为Order / System / Priority / Layer / Agent(s) / Est. Effort工作量估算 S1 次会话、M2–3 次、L4 次以上一次会话指一次能产出完整 GDD 的专注设计对话。7. Phase 5创建系统索引写入阶段7.1 Step 5a起草文档使用 .claude/docs/templates/systems-index.md 模板填充系统索引把 Phase 2–4 的全部数据落盘。模板包含九个核心区块Overview一段话说明游戏机制范围参考核心循环与游戏支柱Systems Enumeration系统枚举表# / System Name / Category / Priority / Status / Design Doc / Depends On隐式推断的系统在名称后标注 (inferred)Categories类别参考表Core / Gameplay / Progression / Economy / Persistence / UI / Audio / Narrative / Meta并注明并非每个游戏都需要所有类别Priority Tiers四档里程碑定义表Dependency Map按五层组织的依赖图Recommended Design Order设计顺序表含 Agent 分配与工作量估算Circular Dependencies循环依赖清单与解决建议High-Risk Systems高风险系统表Risk Type: Technical / Design / Scope 缓解措施无论优先级档位如何都应尽早原型验证Progress Tracker进度追踪指标总系统数、已开始/已评审/已批准的设计文档数、MVP/VS 系统设计数。填充要求填写枚举表、依赖图、推荐设计顺序、高风险系统进度追踪器初始状态全部为 Not Started除非已有 GDD 存在。7.2 Step 5b批准流程呈现文档摘要按类别的系统总数、MVP 系统数、设计顺序前 3 个系统、高风险项。然后询问May I write the systems index todesign/gdd/systems-index.md?必须等到用户明确说 yes 才写入文件。评审模式检查在 spawn CD-SYSTEMS 之前执行solo/lean跳过full正常 spawn。写入后通过 Task spawncreative-director使用 CD-SYSTEMS 门禁。传递的上下文系统索引路径、游戏支柱与核心幻想来自design/gdd/game-concept.md、MVP 优先级系统清单。CD-SYSTEMS 门禁见 .claude/docs/director-gates.md从愿景一致性审查系统分解重点验证MVP 档位的完整系统集合能否集体交付核心幻想是否存在机制不服务任何支柱的系统可能意味着范围蔓延是否存在支柱关键体验没有系统承担是否存在核心循环必需但缺失的系统。若REJECT在 GDD 撰写开始前与用户修订系统集合若CONCERNS在系统索引对应档位章节顶部以 **Creative Director Note**形式记录。7.3 Step 5c更新会话状态写入后若production/session-state/active.md不存在则创建并更新为Task: Systems decompositionStatus: Systems index createdFile: design/gdd/systems-index.mdNext: Design individual system GDDs判定标准系统索引写入成功 →Verdict: COMPLETE用户拒绝写入 →Verdict: BLOCKED。8. Phase 6设计单个系统交接给 /design-system进入该阶段有三种触发方式用户在创建索引后说 yes 要开始设计系统用户调用/map-systems [system-name]用户调用/map-systems next。8.1 Step 6a选择系统若提供了系统名在系统索引中查找若使用next按设计顺序挑选优先级最高的未设计系统若用户刚完成索引询问Would you like to start designing individual systems now? The first system in the design order is [name]. Or would you prefer to stop here and come back later?8.2 Step 6b交接选定系统后调用/design-system [system-name]技能。.claude/skills/design-system/SKILL.md 负责完整的 GDD 撰写流程从游戏概念、系统索引和依赖 GDD 收集上下文立即创建文件骨架逐节走完 8 个必需章节Overview、Player Fantasy、Detailed Design/Rules、Formulas、Edge Cases、Dependencies、Tuning Knobs、Acceptance Criteria交叉引用既有文档防止矛盾路由到专家 Agent 获取领域知识每节批准后立即写入文件完成后运行/design-review并更新系统索引。本技能不重复/design-system的工作流——map-systems拥有系统索引/design-system拥有单个系统的GDD。这是职责边界的明确规定。8.3 Step 6c循环或停止/design-system完成后用AskUserQuestion询问Continue to the next system ([next system name])? / Pick a different system? / Stop here for this session?。若继续返回 Step 6a。9. Phase 7后续步骤建议9.1 索引创建后用AskUserQuestion呈现三个选项[A] Start designing GDDs——运行/design-system [first-system-in-order][B] Ask a director to review the index first——请creative-director或technical-director在投入 10 次 GDD 会话前验证系统集合[C] Stop here for this session。技能特别强调[B] 值得突出推荐在开始 GDD 撰写前让创意总监或技术总监评审完成的系统索引能在范围问题、缺失系统和边界问题被固化到大量文档之前就将其捕获。对全新项目是可选的但值得推荐。9.2 单个 GDD 完成后在新会话中运行/design-review design/gdd/[system].md验证质量所有 MVP GDD 完成后运行/gate-check systems-design。10. 协作协议与上下文窗口管理10.1 全阶段协作协议map-systems在每个阶段遵循协作设计原则与项目根 CLAUDE.md 及 docs/COLLABORATIVE-DESIGN-PRINCIPLE.md 一致Question - Options - Decision - Draft - Approval每个步骤都走这套循环每个决策点都用AskUserQuestionExplain - Capture 模式Phase 2Missing systems? Combine or split?Phase 3Dependency ordering correct?Phase 4Priority assignments match your vision?Phase 5May I write the systems index?Phase 6Start designing, pick different, or stop? 然后交接给/design-system每次文件写入前必须问May I write to [filepath]?增量写入每个系统设计完成后更新系统索引交接单个 GDD 撰写由/design-system负责增量分节写入、交叉引用、设计评审、索引更新会话状态更新每个里程碑索引创建、系统设计完成、优先级变更后写入production/session-state/active.md。三条铁律绝不自动生成完整系统清单并跳过评审直接写入绝不在用户确认前开始设计系统总是展示枚举、依赖和优先级供用户验证。10.2 上下文窗口预警若任意时刻上下文达到或超过70%必须附加以下提示Context is approaching the limit (≥70%).The systems index is saved todesign/gdd/systems-index.md. Open a fresh Claude Code session to continue designing individual GDDs — run/map-systems nextto pick up where you left off.这正是系统索引 会话状态文件的持久化设计价值所在——任何一次压缩、崩溃或新会话都不会丢失已批准的成果。11. 门禁机制小结一次运行中 map-systems 触发的三次导演评审将 .claude/skills/map-systems/SKILL.md 与 .claude/docs/director-gates.md 对照/map-systems完整流程full 模式会触发三次门禁阶段门禁 ID导演 Agent审查焦点判定类型Phase 3 依赖映射批准后TD-SYSTEM-BOUNDARYtechnical-director系统边界是否干净、God Object 风险、反转依赖APPROVE / CONCERNS / REJECTPhase 4 优先级批准后PR-SCOPEproducer里程碑工作量与时间线是否现实REALISTIC / OPTIMISTIC / UNREALISTICPhase 5 索引写入后CD-SYSTEMScreative-director系统集合是否交付核心幻想、是否存在范围蔓延APPROVE / CONCERNS / REJECT评审模式solo/lean/full在每次 spawn 前检查lean模式下这三个逐技能门禁全部跳过只保留/gate-check的 PHASE-GATE这正是其为默认模式的原因——独立开发者可以在里程碑层面获得导演反馈而不会被逐步骤评审拖慢节奏。12. 实战要点速查前置条件必须先运行/brainstorm产生design/gdd/game-concept.md否则map-systems会直接失败并给出明确指引幂等续写design/gdd/systems-index.md已存在时自动进入续写模式用AskUserQuestion让用户选择更新/设计/评审隐式系统是关键概念文档明说的系统通常只是冰山一角用七类推理模式补齐隐藏系统依赖五层法Foundation → Core → Feature → Presentation → Polish从上到下设计瓶颈与循环依赖是首要风险瓶颈系统多依赖者尽早设计循环依赖用接口/契约/同时设计解决优先级四档MVP核心循环必需→ Vertical Slice完整区域体验→ Alpha全部机制粗版→ Full Vision打磨与锦上添花设计顺序 依赖序 优先级MVP Foundation 最先写 GDDWhy 列要讲玩家体验纯技术理由X 依赖 Y不足以支撑优先级判断交接原则map-systems只拥有系统索引单个系统的 GDD 一律交给/design-system断点恢复/map-systems next自动选择最高优先级未设计系统配合production/session-state/active.md实现跨会话无缝续跑上下文管理达到 70% 时保存索引、开启新会话继续。13. 与相邻技能的衔接全景map-systems不是孤立存在的它与 CCGS 流水线中的其他技能构成完整闭环各技能定义均位于 .claude/skills/ 目录相邻技能关系衔接方式.claude/skills/brainstorm/SKILL.md上游产出game-concept.md与game-pillars.md是 map-systems 的输入材料.claude/skills/design-system/SKILL.md下游按索引设计顺序逐个撰写系统 GDD并在完成后回写索引状态.claude/skills/design-review/SKILL.md下游在新会话中独立评审每个已完成的 GDD.claude/skills/gate-check/SKILL.md阶段门禁所有 MVP GDD 完成且评审后执行pre-production阶段转换检查.claude/skills/start/SKILL.md引导首次会话设置production/review-mode.txt决定本次运行的评审模式一次典型的首次使用路径是/start引导与评审模式设置→/brainstorm概念→/map-systems系统拆解→/map-systems next逐个交接设计→/design-review评审→/gate-check pre-production阶段门禁。map-systems在其中扮演的是把创意想法变成可执行设计计划的关键转换器其产出的design/gdd/systems-index.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 系统拆解技能 map-systems 完全指南：从游戏概念到系统索引的流水线
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导读map-systems是 Claude Code Game StudiosCCGS概念 → 系统 → GDD → 实现流水线中的核心枢纽技能它接收/brainstorm产出的游戏概念文档通过七阶段协作流程将概念拆解为一个个可独立设计的游戏系统映射系统间依赖关系按里程碑分配优先级并最终生成一份可长期维护的systems-index.md系统索引。读完本文你将掌握 CCGS 中系统拆解这一环节的完整方法论——包括显式/隐式系统识别模式、依赖分层排序、循环依赖检测、里程碑优先级分配、三档导演门禁review mode机制以及如何通过/map-systems next让设计流水线自动推进到下一个最高优先级系统。1. 技能定位连接概念与 GDD 的中间层在 CCGS 的协作设计流水线中map-systems处于承上启下的位置上游/brainstorm产出design/gdd/game-concept.md游戏概念文档与design/gdd/game-pillars.md游戏支柱文档本体/map-systems把概念拆解为系统清单、依赖图和优先级排序写入design/gdd/systems-index.md下游/design-system依据系统索引逐个撰写系统 GDD详见 .claude/skills/design-system/SKILL.md。技能本身的 frontmatter 定义如下见 .claude/skills/map-systems/SKILL.mdname: map-systems description: Decompose a game concept into individual systems, map dependencies, prioritize design order, and create the systems index. argument-hint: [next | system-name] [--review full|lean|solo] user-invocable: true allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, TodoWrite, Task从中可以看出该技能的三个设计特征用户可主动调用user-invocable: true且参数可选全程协作AskUserQuestion被列为核心工具技能在每个决策点都要征求用户意见而非静默生成可跨会话恢复TodoWrite与production/session-state/active.md配合保证长流程中断后能无缝续跑。CCGS 根级 CLAUDE.md 将整个项目的协作基调定义为 User-driven collaboration, not autonomous executionmap-systems正是这一原则的典型执行者。2. 调用方式与参数解析/map-systems支持两种运行模式见 .claude/skills/map-systems/SKILL.md Parse Arguments 一节调用形式行为/map-systems无参数执行完整的系统拆解工作流Phase 1–5创建或更新系统索引/map-systems next从索引中挑选优先级最高且尚未设计的系统交接给/design-system即 Phase 6/map-systems [system-name]直接指定要设计的系统名进入 Phase 6 交接流程2.1 评审模式Review Mode解析技能在每次运行时只解析一次评审模式供本次运行所有导演门禁共用优先级如下若调用时显式传入--review [full|lean|solo]则使用该值否则读取production/review-mode.txt中的值否则默认lean。这一解析模式与 .claude/docs/director-gates.md 中定义的全局门禁机制完全一致。该文档规定production/review-mode.txt是在/start时一次性设置的全局配置文件内只放一个词full、lean或solo而--review参数则只对本次运行生效。三种模式的含义差异影响门禁是否执行模式行为适用场景full所有门禁激活每个工作流步骤都接受导演评审团队协作、学习型用户、希望每个步骤都有导演反馈lean仅 PHASE-GATE/gate-check生效逐技能门禁跳过默认——独立开发者与小团队导演只在里程碑节点介入solo所有导演门禁全部跳过Game Jam、原型开发、追求最高速度3. Phase 1读取概念前置上下文系统拆解必须有原材料因此 Phase 1 强制读取游戏概念文档必读项design/gdd/game-concept.md。如果该文件缺失技能必须用清晰的消息直接失败No game concept found atdesign/gdd/game-concept.md. Run/brainstormfirst to create one, then come back to decompose it into systems.可选项存在即读design/gdd/game-pillars.md——游戏支柱会约束优先级与范围判断design/gdd/systems-index.md——若已存在则从上次断点续写更新而非推倒重建用 Glob 扫描design/gdd/*.md——检查哪些系统 GDD 已经存在。若系统索引已存在技能需先读取并展示当前状态然后用AskUserQuestion询问用户The systems index already exists with [N] systems ([M] designed, [K] not started). What would you like to do?选项为Update the index with new systems更新索引、Design the next undesigned system设计下一个未设计系统、Review and revise priorities评审并修订优先级。这一步保证了技能的可恢复性与幂等性——重复调用不会丢失已有工作。4. Phase 2系统枚举协作核心系统枚举是整个技能的创意核心它要求人类判断参与因为概念文档几乎不会显式罗列每一个系统。该阶段分三步4.1 Step 2a提取显式系统扫描概念文档中直接提到的系统与机制重点看四个章节Core Mechanics 章节最显式Core Loop 章节隐含每个循环层级由哪些系统驱动Technical Considerations 章节网络、程序化生成等MVP Definition 章节必需功能 必需系统。4.2 Step 2b识别隐式系统对每个显式系统找出它隐含的隐藏系统。游戏的系统数量永远多于概念文档写出来的数量。技能内置了七类典型推理模式概念提到隐含系统Inventory背包物品数据库、装备槽、重量/容量规则、背包 UI、物品序列化用于存档/读档Combat战斗伤害计算、生命系统、命中判定、状态效果、敌人 AI、战斗 UI血条、伤害数字、死亡/重生Open world开放世界流式加载/区块划分、LOD 系统、快速旅行、地图/小地图、兴趣点追踪、世界状态持久化Multiplayer多人网络层、大厅/匹配、状态同步、反作弊、网络 UIping、玩家列表Crafting制作配方数据库、材料采集、制作 UI、成功/失败机制、配方发现/学习Dialogue对话对话树系统、对话 UI、选择追踪、NPC 状态管理、本地化钩子Progression成长XP 系统、升级机制、技能树、解锁追踪、成长 UI、成长存档数据技能要求在对话文本中解释每个隐式系统为何必要配示例让用户理解推理链而非只看到结论。4.3 Step 2c用户审核按类别组织枚举结果为每个系统展示名称、类别、一句话描述、来源显式/隐式。随后用AskUserQuestion收集三类反馈Are there systems missing from this list?是否有遗漏Should any of these be combined or split?是否有需要合并或拆分Are there systems listed that this game does NOT need?是否有本游戏不需要的迭代直到用户批准枚举结果才进入下一阶段。5. Phase 3依赖映射协作核心一个系统依赖另一个系统指的是没有后者前者就无法运作。5.1 Step 3a依赖启发式三类依赖判断依据输入/输出依赖系统 A 产出的数据是系统 B 的输入结构性依赖系统 A 提供了系统 B 要插入的框架UI 依赖每个玩法系统都有对应的 UI 系统依赖它但 UI 在玩法系统之后设计。5.2 Step 3b按依赖序分层将所有系统排成五层从上到下设计、构建Foundation地基层零依赖的系统最先设计、最先构建Core核心层只依赖地基层系统的系统Feature功能层依赖核心层系统的系统Presentation表现层包裹玩法系统的 UI 与反馈系统Polish打磨层元系统、教程、数据分析、无障碍。这一分层结构直接对应系统索引模板中 .claude/docs/templates/systems-index.md 的 Dependency Map 章节——模板要求按 Foundation / Core / Feature / Presentation / Polish 五层组织依赖图每层列出系统及其放置理由。5.3 Step 3c检测循环依赖检查依赖图中是否存在环。若发现循环依赖向用户高亮提出解决方案接口抽象interface abstraction、同时设计simultaneous design、或通过定义两个系统间的契约来打破循环。5.4 Step 3d呈现给用户 技术总监门禁以分层列表展示依赖图并高亮三类风险循环依赖瓶颈系统很多系统依赖它——高风险无依赖者的叶节点系统低风险可晚设计。用AskUserQuestion询问Does this dependency ordering look right? Any dependencies Im missing or that should be removed?评审模式检查在 spawn TD-SYSTEM-BOUNDARY 之前执行solo→ 跳过记录 TD-SYSTEM-BOUNDARY skipped — Solo mode.直接进入优先级分配lean→ 跳过非 PHASE-GATE记录 TD-SYSTEM-BOUNDARY skipped — Lean mode.直接进入优先级分配full→ 正常 spawn。依赖映射获得批准后通过 Task 工具 spawntechnical-director使用 TD-SYSTEM-BOUNDARY 门禁定义于 .claude/docs/director-gates.md然后才能进入优先级分配。需要传递给门禁的上下文包括依赖图摘要、分层分配、瓶颈系统清单、循环依赖解决方案。根据 .claude/docs/director-gates.md 中 TD-SYSTEM-BOUNDARY 门禁的定义技术总监从架构视角审查系统分解重点检查系统边界是否干净——每个系统是否拥有独立关注点、重叠最小是否存在 God Object 风险系统承担过多职责依赖排序是否会造成实现时序问题边界划分是否隐含共享状态问题导致实现时紧耦合是否存在反转依赖地基层系统实际依赖功能层系统。门禁判定结果处理若REJECT需与用户一起修订系统边界后再进入优先级分配若CONCERNS将问题内联记录到系统索引中并继续。6. Phase 4优先级分配协作核心6.1 Step 4a基于概念的自动分配按里程碑需求用以下启发式进行初始分配优先级档位判定标准MVP概念文档 Required for MVP 章节提到的系统加上它们的 Foundation 层依赖Vertical Slice某个区域内完整体验所需的系统Alpha其余所有玩法系统Full Vision打磨、元系统、锦上添花类系统这一档位体系与系统索引模板的 Priority Tiers 章节一致见 .claude/docs/templates/systems-index.mdMVP 用于验证是否好玩Vertical Slice 用于演示完整体验Alpha 是完整机制范围 占位内容Full Vision 则是打磨与补全。6.2 Step 4b用户审核与Why列指导用表格展示各系统的优先级分配解释每个档位的放置理由然后用AskUserQuestion询问Do these priority assignments match your vision? Which systems should be higher or lower priority?技能特别强调Why 列的撰写指导解释放置理由时要混合技术必要性与玩家体验理由不能只写纯技术理由如战斗需要伤害数学而要关联玩家体验。技能给出的优质示例Required for the core loop — without it, placement decisions have no consequence (Pillar 2: Placement is the Puzzle)核心循环必需——没有它放置决策就没有后果对应支柱 2放置即谜题Ballistas punch-through identity is established here — this stat definition is what makes it feel different from Archer弩炮的穿透身份在此确立——这个属性定义正是它与弓手手感差异的来源Foundation for all economy decisions — players must understand upgrade costs to make meaningful placement choices所有经济决策的基础——玩家必须理解升级成本才能做出有意义的放置选择。当系统直接塑造玩家体验时单纯的技术必要性X 依赖 Y是不充分的理由。评审模式检查在 spawn PR-SCOPE 之前执行solo/lean跳过并记录full正常 spawn。优先级批准后通过 Task spawnproducer使用 PR-SCOPE 门禁。需要传递的上下文包括各里程碑档位的系统总数、每档的估算实现工作量系统数 × 平均复杂度、团队规模、声明的项目时间线。PR-SCOPE 门禁见 .claude/docs/director-gates.md返回三种判定REALISTIC范围与产能匹配、OPTIMISTIC建议具体调整、UNREALISTIC阻塞——时间线或 MVP 必须修订。若判定为 UNREALISTIC需要先提供修订优先级档位分配的选择再写索引若为 CONCERNS记录后继续。6.3 Step 4c确定设计顺序将依赖排序与优先级档位结合产出最终设计顺序MVP Foundation 系统第一MVP Core 系统第二MVP Feature 系统第三Vertical Slice 的 Foundation/Core 系统……依此类推。这就是团队撰写 GDD 的顺序。该顺序在 .claude/docs/templates/systems-index.md 中由 Recommended Design Order 表格承载表格列为Order / System / Priority / Layer / Agent(s) / Est. Effort工作量估算 S1 次会话、M2–3 次、L4 次以上一次会话指一次能产出完整 GDD 的专注设计对话。7. Phase 5创建系统索引写入阶段7.1 Step 5a起草文档使用 .claude/docs/templates/systems-index.md 模板填充系统索引把 Phase 2–4 的全部数据落盘。模板包含九个核心区块Overview一段话说明游戏机制范围参考核心循环与游戏支柱Systems Enumeration系统枚举表# / System Name / Category / Priority / Status / Design Doc / Depends On隐式推断的系统在名称后标注 (inferred)Categories类别参考表Core / Gameplay / Progression / Economy / Persistence / UI / Audio / Narrative / Meta并注明并非每个游戏都需要所有类别Priority Tiers四档里程碑定义表Dependency Map按五层组织的依赖图Recommended Design Order设计顺序表含 Agent 分配与工作量估算Circular Dependencies循环依赖清单与解决建议High-Risk Systems高风险系统表Risk Type: Technical / Design / Scope 缓解措施无论优先级档位如何都应尽早原型验证Progress Tracker进度追踪指标总系统数、已开始/已评审/已批准的设计文档数、MVP/VS 系统设计数。填充要求填写枚举表、依赖图、推荐设计顺序、高风险系统进度追踪器初始状态全部为 Not Started除非已有 GDD 存在。7.2 Step 5b批准流程呈现文档摘要按类别的系统总数、MVP 系统数、设计顺序前 3 个系统、高风险项。然后询问May I write the systems index todesign/gdd/systems-index.md?必须等到用户明确说 yes 才写入文件。评审模式检查在 spawn CD-SYSTEMS 之前执行solo/lean跳过full正常 spawn。写入后通过 Task spawncreative-director使用 CD-SYSTEMS 门禁。传递的上下文系统索引路径、游戏支柱与核心幻想来自design/gdd/game-concept.md、MVP 优先级系统清单。CD-SYSTEMS 门禁见 .claude/docs/director-gates.md从愿景一致性审查系统分解重点验证MVP 档位的完整系统集合能否集体交付核心幻想是否存在机制不服务任何支柱的系统可能意味着范围蔓延是否存在支柱关键体验没有系统承担是否存在核心循环必需但缺失的系统。若REJECT在 GDD 撰写开始前与用户修订系统集合若CONCERNS在系统索引对应档位章节顶部以 **Creative Director Note**形式记录。7.3 Step 5c更新会话状态写入后若production/session-state/active.md不存在则创建并更新为Task: Systems decompositionStatus: Systems index createdFile: design/gdd/systems-index.mdNext: Design individual system GDDs判定标准系统索引写入成功 →Verdict: COMPLETE用户拒绝写入 →Verdict: BLOCKED。8. Phase 6设计单个系统交接给 /design-system进入该阶段有三种触发方式用户在创建索引后说 yes 要开始设计系统用户调用/map-systems [system-name]用户调用/map-systems next。8.1 Step 6a选择系统若提供了系统名在系统索引中查找若使用next按设计顺序挑选优先级最高的未设计系统若用户刚完成索引询问Would you like to start designing individual systems now? The first system in the design order is [name]. Or would you prefer to stop here and come back later?8.2 Step 6b交接选定系统后调用/design-system [system-name]技能。.claude/skills/design-system/SKILL.md 负责完整的 GDD 撰写流程从游戏概念、系统索引和依赖 GDD 收集上下文立即创建文件骨架逐节走完 8 个必需章节Overview、Player Fantasy、Detailed Design/Rules、Formulas、Edge Cases、Dependencies、Tuning Knobs、Acceptance Criteria交叉引用既有文档防止矛盾路由到专家 Agent 获取领域知识每节批准后立即写入文件完成后运行/design-review并更新系统索引。本技能不重复/design-system的工作流——map-systems拥有系统索引/design-system拥有单个系统的GDD。这是职责边界的明确规定。8.3 Step 6c循环或停止/design-system完成后用AskUserQuestion询问Continue to the next system ([next system name])? / Pick a different system? / Stop here for this session?。若继续返回 Step 6a。9. Phase 7后续步骤建议9.1 索引创建后用AskUserQuestion呈现三个选项[A] Start designing GDDs——运行/design-system [first-system-in-order][B] Ask a director to review the index first——请creative-director或technical-director在投入 10 次 GDD 会话前验证系统集合[C] Stop here for this session。技能特别强调[B] 值得突出推荐在开始 GDD 撰写前让创意总监或技术总监评审完成的系统索引能在范围问题、缺失系统和边界问题被固化到大量文档之前就将其捕获。对全新项目是可选的但值得推荐。9.2 单个 GDD 完成后在新会话中运行/design-review design/gdd/[system].md验证质量所有 MVP GDD 完成后运行/gate-check systems-design。10. 协作协议与上下文窗口管理10.1 全阶段协作协议map-systems在每个阶段遵循协作设计原则与项目根 CLAUDE.md 及 docs/COLLABORATIVE-DESIGN-PRINCIPLE.md 一致Question - Options - Decision - Draft - Approval每个步骤都走这套循环每个决策点都用AskUserQuestionExplain - Capture 模式Phase 2Missing systems? Combine or split?Phase 3Dependency ordering correct?Phase 4Priority assignments match your vision?Phase 5May I write the systems index?Phase 6Start designing, pick different, or stop? 然后交接给/design-system每次文件写入前必须问May I write to [filepath]?增量写入每个系统设计完成后更新系统索引交接单个 GDD 撰写由/design-system负责增量分节写入、交叉引用、设计评审、索引更新会话状态更新每个里程碑索引创建、系统设计完成、优先级变更后写入production/session-state/active.md。三条铁律绝不自动生成完整系统清单并跳过评审直接写入绝不在用户确认前开始设计系统总是展示枚举、依赖和优先级供用户验证。10.2 上下文窗口预警若任意时刻上下文达到或超过70%必须附加以下提示Context is approaching the limit (≥70%).The systems index is saved todesign/gdd/systems-index.md. Open a fresh Claude Code session to continue designing individual GDDs — run/map-systems nextto pick up where you left off.这正是系统索引 会话状态文件的持久化设计价值所在——任何一次压缩、崩溃或新会话都不会丢失已批准的成果。11. 门禁机制小结一次运行中 map-systems 触发的三次导演评审将 .claude/skills/map-systems/SKILL.md 与 .claude/docs/director-gates.md 对照/map-systems完整流程full 模式会触发三次门禁阶段门禁 ID导演 Agent审查焦点判定类型Phase 3 依赖映射批准后TD-SYSTEM-BOUNDARYtechnical-director系统边界是否干净、God Object 风险、反转依赖APPROVE / CONCERNS / REJECTPhase 4 优先级批准后PR-SCOPEproducer里程碑工作量与时间线是否现实REALISTIC / OPTIMISTIC / UNREALISTICPhase 5 索引写入后CD-SYSTEMScreative-director系统集合是否交付核心幻想、是否存在范围蔓延APPROVE / CONCERNS / REJECT评审模式solo/lean/full在每次 spawn 前检查lean模式下这三个逐技能门禁全部跳过只保留/gate-check的 PHASE-GATE这正是其为默认模式的原因——独立开发者可以在里程碑层面获得导演反馈而不会被逐步骤评审拖慢节奏。12. 实战要点速查前置条件必须先运行/brainstorm产生design/gdd/game-concept.md否则map-systems会直接失败并给出明确指引幂等续写design/gdd/systems-index.md已存在时自动进入续写模式用AskUserQuestion让用户选择更新/设计/评审隐式系统是关键概念文档明说的系统通常只是冰山一角用七类推理模式补齐隐藏系统依赖五层法Foundation → Core → Feature → Presentation → Polish从上到下设计瓶颈与循环依赖是首要风险瓶颈系统多依赖者尽早设计循环依赖用接口/契约/同时设计解决优先级四档MVP核心循环必需→ Vertical Slice完整区域体验→ Alpha全部机制粗版→ Full Vision打磨与锦上添花设计顺序 依赖序 优先级MVP Foundation 最先写 GDDWhy 列要讲玩家体验纯技术理由X 依赖 Y不足以支撑优先级判断交接原则map-systems只拥有系统索引单个系统的 GDD 一律交给/design-system断点恢复/map-systems next自动选择最高优先级未设计系统配合production/session-state/active.md实现跨会话无缝续跑上下文管理达到 70% 时保存索引、开启新会话继续。13. 与相邻技能的衔接全景map-systems不是孤立存在的它与 CCGS 流水线中的其他技能构成完整闭环各技能定义均位于 .claude/skills/ 目录相邻技能关系衔接方式.claude/skills/brainstorm/SKILL.md上游产出game-concept.md与game-pillars.md是 map-systems 的输入材料.claude/skills/design-system/SKILL.md下游按索引设计顺序逐个撰写系统 GDD并在完成后回写索引状态.claude/skills/design-review/SKILL.md下游在新会话中独立评审每个已完成的 GDD.claude/skills/gate-check/SKILL.md阶段门禁所有 MVP GDD 完成且评审后执行pre-production阶段转换检查.claude/skills/start/SKILL.md引导首次会话设置production/review-mode.txt决定本次运行的评审模式一次典型的首次使用路径是/start引导与评审模式设置→/brainstorm概念→/map-systems系统拆解→/map-systems next逐个交接设计→/design-review评审→/gate-check pre-production阶段门禁。map-systems在其中扮演的是把创意想法变成可执行设计计划的关键转换器其产出的design/gdd/systems-index.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），仅供参考