[System Name]

[System Name]

【免费下载链接】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

Status: In DesignAuthor: [user + agents]Last Updated: [today's date]Implements Pillar: [from context]

Overview

[To be designed]

Player Fantasy

[To be designed]

Detailed Design

Core Rules

[To be designed]

States and Transitions

[To be designed]

Interactions with Other Systems

[To be designed]

Formulas

[To be designed]

Edge Cases

[To be designed]

Dependencies

[To be designed]

Tuning Knobs

[To be designed]

Visual/Audio Requirements

[To be designed]

UI Requirements

[To be designed]

Acceptance Criteria

[To be designed]

Open Questions

[To be designed]

写入前同样要征得许可（"May I create the skeleton file at `design/gdd/[system-name].md`?"）。骨架落盘后更新 `production/session-state/active.md`——用 Glob 检查文件是否存在：不存在则用 Write 创建（**绝不要对可能不存在的文件执行 Edit**），存在则用 Edit 更新字段，记录任务、当前章节（Starting）、目标文件路径。 值得补充的是，仓库中的 [模板文件](https://link.gitcode.com/i/0066b86c187b8d1f622be55a302c9f91) 比骨架更完整，还包含 Summary（面向分层上下文加载的速览）、Game Feel（手感目标，含输入延迟、帧数据、Impact Moments 等表）、Cross-References（机器可校验的显式依赖声明表）等扩展章节；而 [design/CLAUDE.md](https://link.gitcode.com/i/95c5c123dc277a2aab0272111c09d31d) 规定的最低必需集合是 8 个章节：Overview、Player Fantasy、Detailed Rules、Formulas、Edge Cases、Dependencies、Tuning Knobs、Acceptance Criteria。写作时按技能骨架推进，模板中的扩展章节则按需启用。 ## 五、Phase 4：逐节设计循环——协作协议的心脏 ### 5.1 Section Cycle：七步闭环 对每个章节严格按以下循环执行：

Context -> Questions -> Options -> Decision -> Draft -> Approval -> Write

1. **Context**：说明本节需要包含什么，并摆出依赖 GDD 中约束本节的既有决策； 2. **Questions**：针对本节提出澄清性问题，受限问题用 `AskUserQuestion`，开放探索用对话文本； 3. **Options**：当本节涉及设计选择时，给出 2–4 个方案并附利弊，用 `AskUserQuestion` 捕获决策； 4. **Decision**：用户选择方案或给出自定义方向； 5. **Draft**：在对话中呈现草稿供审阅，并标记任何关于未设计依赖的临时假设； 6. **Approval**：**草稿与审批组件必须在同一条回复中出现**。技能原文将「只给草稿不给审批组件」定性为协议违规（protocol violation）——用户在空白提示符前会失去前进路径。选项固定为 `[A] Approve — write it to file` / `[B] Make changes — describe what to fix` / `[C] Start over`； 7. **Write**：用 Edit 替换占位符。**关键坑**：`old_string` 必须包含章节标题（如 `"## [Section Name]\n\n[To be designed]"`），绝不能只匹配 `[To be designed]`——因为多个章节共用同一占位符，Edit 工具要求唯一匹配。 ### 5.2 写后注册表冲突检查（仅 C、D 两节） Detailed Design 与 Formulas 两节写入后，需扫描本节内容中出现在注册表里的实体名、物品名、公式名与数值常量，逐一比对： - 值不一致 → **立即**在开始下一节前呈现冲突：「Registry conflict: [name] is registered in [source GDD] as [registry_value]. This section just wrote [new_value]. Which is correct?」绝不允许默默继续； - 值未登记 → 标记为注册候选（在 Phase 5 处理）。 每写完一节，同样更新 `production/session-state/active.md` 记录已完成章节。这就是「增量写作」的意义所在：**每一节获批后立即落盘，任何中断都不会丢失已批准的内容**（详见第七节 Recovery & Resume）。 ### 5.3 Section A：Overview——行为层，而非实现层 **目标**：一段陌生人也能读懂的文字。技能要求在构建选择组件前先根据系统类别与层级推导推荐项（Foundation/Infrastructure 层 → 技术框架视角；玩家面向类别 → 双视角），并在对应选项后追加 `(Recommended)`。 三个 Tab 的 Framing 问题必须在草稿**之前**询问（禁止自己代答后自动起草）： - **Framing**：「How should the overview frame this system?」选项：`[A] 数据/基础设施层（技术框架）` / `[B] 玩家可见效果（设计框架）` / `[C] 两者兼顾——描述数据层与玩家影响`； - **ADR ref**：「Should the overview reference the existing ADR for this system?」选项：`[A] 引用 ADR 补充实现细节` / `[B] 保持 GDD 纯设计层面`（推荐项取决于 Glob `docs/architecture/adr-*.md` 后是否命中本系统）； - **Fantasy**：「Does this system have a player fantasy worth stating?」选项：`[A] 是——玩家直接感受` / `[B] 否——纯基础设施`。 技能在此处明确划定了**设计/实现边界**：Overview 的提问必须停留在行为层面（系统*做什么*），一旦冒出实现问题（如「用 Autoload 单例还是信号总线？」），就记为「→ becomes an ADR」并跳过——实现模式属于 `/architecture-decision` 技能，GDD 描述行为，ADR 描述实现手法。 ### 5.4 Section B：Player Fantasy——创意的强制外部输入 **目标**：情感靶心——玩家应当*感受*到什么。技能同样要求先按类别推导推荐项（玩家面向类别 → Direct；基础设施 → Indirect；混合类别 → Both），再询问框架问题。 **强制委托**（MANDATORY）：在用户给出框架答案之后、起草之前，**必须**通过 Task 派发 `creative-director`，提供系统名、框架答案（direct/indirect/both）、游戏支柱、参考游戏与概念摘要，要求其产出 2–3 个候选框架（情感/力量幻想、锚定玩家时刻、语气与语言）。技能明文规定：**未先咨询 creative-director 不得起草本节**——框架答案决定幻想*是什么*，creative-director 决定幻想*如何被描述*。 ### 5.5 Section C：Detailed Design——程序员无歧义实现的前提 **目标**：一份程序员无需提问即可实现的规格，通常是最大的一节，拆为三个子节： 1. **Core Rules**：顺序流程用编号规则，属性用列表； 2. **States and Transitions**：有状态就用表格穷举每个状态与每条合法转移； 3. **Interactions with Other Systems**：对每个依赖（上下游）明确流入什么数据、流出什么数据、接口归属谁。 提问模板：让用户逐步讲述一次典型使用；玩家的决策点有哪些；玩家**不能**做什么（约束与能力同等重要）。 **强制委托**：起草前必须按第 5.9 节的专家路由表并行派发 Primary Agent 与 Supporting Agents，提供系统名、概念摘要、支柱、依赖 GDD 摘录与本节信息；专家间的分歧通过 `AskUserQuestion` 呈现给用户裁决；收到专家输入后才允许起草。技能特别强调：`systems-designer` 对规则与机制的复核能抓住主会话漏掉的设计缺口。 ### 5.6 Section D：Formulas——每条公式必须有变量表 **目标**：所有数学公式，变量定义、取值范围、边界情况齐备。技能用「完成度强制结构」杜绝 `[Formula TBD]` 或纯散文描述：

The [formula_name] formula is defined as:

[formula_name] = [expression]

Variables:| Variable | Symbol | Type | Range | Description | |----------|--------|------|-------|-------------| | [name] | [sym] | float/int | [min–max] | [what it represents] |

Output Range:[min] to [max] under normal play; [behaviour at extremes]Example:[worked example with real numbers]

其背后的工程理由是：**没有变量表的公式，实现时必然靠猜**。提问模板覆盖核心计算、缩放模型（线性/对数/阶梯）与早/中/后期输出范围。 **强制委托**：提出任何公式或平衡数值前，必须并行派发专家——`systems-designer` 恒必派（提供 Section C 核心规则、调优目标与依赖 GDD 平衡上下文）；经济/成本类系统额外派发 `economy-designer`（校验成本曲线与比率）。专家提案经由 `AskUserQuestion` 交用户裁决，主会话只负责落盘。技能明确警告：**没有专家输入就不要自造公式数值**——没有平衡设计经验的用户无法凭空评估裸数字，他们需要专家的推理过程。 ### 5.7 Section E：Edge Cases——有条件的精确结果，而非「妥善处理」 **目标**：显式处理反常情况，避免它们变成 bug。每条边界情况必须按固定格式写出： - **If [condition]**: [exact outcome]. [rationale if non-obvious] 示例（术语按游戏域适配）： - **If [resource] reaches 0 while [protective condition] is active**: hold at minimum until condition ends, then apply consequence. - **If two [triggers/events] fire simultaneously**: resolve in [defined priority order]; ties use [defined tiebreak rule]. 禁止写「handle appropriately」这类模糊条目——**没有解决方案的边界情况是未决设计问题，不是规格**。提问模板覆盖：零值/最大值/越界时发生什么？两条规则同时生效时？玩家发现非预期交互（degenerate strategies）时？ **强制委托**：定稿前派发 `systems-designer`，提供已完成的本节 C/D，请其从公式与规则空间找出主会话可能遗漏的边界情况；叙事系统额外派发 `narrative-director`。 ### 5.8 Section F：Dependencies——双向一致的地图 **目标**：记录每条系统连接的指向与性质。本节在上下文收集阶段已部分预填，剩余工作是与用户核对：是否遗漏依赖；每条依赖的具体数据接口；硬依赖（缺之不可）与软依赖（增强性）之分。 **交叉校验**：本节必须双向一致——若本系统列出「depends on Combat」，则 Combat 的 GDD 应列出「depended on by [本系统]」。发现单向依赖必须标记纠正。 ### 5.9 Section G：Tuning Knobs——设计师可调的一切 **目标**：每个可调值及其安全范围与极端行为。提问模板：哪些值应在不改代码的前提下可调？每个旋钮调太高/太低会破坏什么？哪些旋钮相互耦合（改 A 使 B 失效）？若公式复杂，可委托 `systems-designer` 从公式变量推导旋钮。**交叉校验**：依赖 GDD 中影响本系统的旋钮直接引用其出处，不创建重复旋钮——指向事实源。 ### 5.10 Section H：Acceptance Criteria——QA 无需读 GDD 即可验证 **目标**：可测试条件。每条标准强制使用 Given-When-Then 格式： - **GIVEN** [initial state], **WHEN** [action or trigger], **THEN** [measurable outcome] 至少覆盖：Section C 每条核心规则一条标准、Section D 每条公式一条标准。禁止「the system works as designed」这种空话——**每条标准必须能被 QA 测试员在不读 GDD 的情况下独立验证**。提问模板还包括性能预算（帧时间、内存）与 QA 首先检查什么。 **强制委托**：定稿前派发 `qa-lead`，提供已完成的 C/D/E 章节，验证标准是否独立可测且覆盖全部核心规则与公式。 ### 5.11 可选章节：Visual/Audio、UI、Open Questions 技能特别澄清了「可选」的边界——**Visual/Audio 对以下系统类别是必需的，不得提议跳过**： - Combat, damage, health - UI systems (HUD, menus) - Animation, character movement - Visual effects, particles, shaders - Character systems - Dialogue, quests, lore - Level/world systems 对必需类别：起草前必须派发 `art-director`，提供系统名、概念、支柱与 art bible 第 1–4 节（若存在），要求其给出 (1) 系统事件的 VFX 与视觉反馈需求、(2) 动画/视觉风格约束、(3) 最适用的 art bible 原则；**不允许此类系统留下 `[To be designed]`**。 对非必需类别（Foundation/Infrastructure、Economy、AI/pathfinding、Camera/input），8 个必需章节完成后询问「是否补充 Visual/Audio、UI 或记录未决问题」，选项为 `Yes, all three` / `Just open questions` / `Skip — I'll add these later`。 写作完成后还有两个**下游接力标记**：Visual/Audio 有真实内容时，输出提示后续运行 `/asset-spec system:[system-name]` 从本节产出逐资产视觉描述与生成提示词；UI Requirements 有真实内容时，输出 UX Flag，提示在 Phase 4（Pre-Production）阶段运行 `/ux-design` 为每个屏幕/HUD 元素创建 UX 规格，且引用 UI 的 story 应引用 `design/ux/[screen].md` 而非 GDD 本身。 ## 六、专家路由表：谁为哪个域负责 技能第 6 节定义了完整的委托矩阵，是 Section C 强制委托的权威路由依据： | 系统类别 | Primary Agent | Supporting Agent(s) | |---------|---------------|---------------------| | Foundation/Infrastructure（事件总线、存档、场景管理、服务定位） | `systems-designer` | `gameplay-programmer`（可行性）、`engine-programmer`（引擎集成） | | Combat, damage, health | `game-designer` | `systems-designer`（公式）、`ai-programmer`（敌方 AI）、`art-director`（命中反馈视觉方向、VFX 意图） | | Economy, loot, crafting | `economy-designer` | `systems-designer`（曲线）、`game-designer`（循环） | | Progression, XP, skills | `game-designer` | `systems-designer`（曲线）、`economy-designer`（消耗点） | | Dialogue, quests, lore | `game-designer` | `narrative-director`（故事）、`writer`（内容）、`art-director`（角色视觉档案、电影感色调） | | UI systems (HUD, menus) | `game-designer` | `ux-designer`（流程）、`ui-programmer`（可行性）、`art-director`（视觉风格方向）、`technical-artist`（渲染/着色器约束） | | Audio systems | `game-designer` | `audio-director`（方向）、`sound-designer`（规格） | | AI, pathfinding, behavior | `game-designer` | `ai-programmer`（实现）、`systems-designer`（评分） | | Level/world systems | `game-designer` | `level-designer`（空间）、`world-builder`（世界观） | | Camera, input, controls | `game-designer` | `ux-designer`（手感）、`gameplay-programmer`（可行性） | | Animation, character movement | `game-designer` | `art-director`（动画风格、姿态语言）、`technical-artist`（骨骼/混合约束）、`gameplay-programmer`（手感） | | Visual effects, particles, shaders | `game-designer` | `art-director`（VFX 视觉方向）、`technical-artist`（性能预算、着色器复杂度）、`systems-designer`（触发/状态集成） | | Character systems (stats, archetypes) | `game-designer` | `art-director`（角色视觉原型）、`narrative-director`（角色弧光对齐）、`systems-designer`（属性公式） | 委托纪律同样严格：Task 调用时提供系统名、概念摘要、依赖 GDD 摘录、当前章节与待解答问题；专家只返回分析/提案，**不直接写文件**——所有文件写入归主会话所有，最终决策权始终在用户。 ## 七、Phase 5：设计后校验与收尾 ### 7.1 自检（5a）：以文件为真相源 全部章节写完后，**从文件（而非对话记忆）重读完整 GDD**——文件才是事实源。核对：8 个必需章节均有真实内容；公式引用了已定义变量；边界情况都有解决方案；依赖均列出接口；验收标准可测试。 ### 7.2 CD-GDD-ALIGN：创意总监支柱对齐门 正式定稿前按 [director-gates.md](https://link.gitcode.com/i/97f4827ac1e7b94eb841bb08e5d45098) 中的 **CD-GDD-ALIGN** 门派发 `creative-director`，传入完整 GDD 路径、游戏支柱与 MDA 审美目标。评审结果按标准规则处理，并记录在 GDD 状态头：`> **Creative Director Review (CD-GDD-ALIGN)**: APPROVED [date] / CONCERNS (accepted) [date] / REVISED [date]`。 **但此门受 review 模式管控**：`solo` 与 `lean` 模式跳过（分别记录 "CD-GDD-ALIGN skipped — Solo mode" / "— Lean mode"），仅 `full` 模式正常派发。这与 [director-gates.md](https://link.gitcode.com/i/97f4827ac1e7b94eb841bb08e5d45098) 中「lean 只保留 PHASE-GATE」的全局规则一致——这也是为什么 `--review` 在技能开头就要一次性解析并全程持有。 ### 7.3 实体注册表更新（5b） 扫描完成的 GDD，找出应登记的跨系统事实：带属性/掉落物的具名实体、带价值/重量/类别的具名物品、带变量与输出范围的具名公式、在多处被按值引用的具名常量。先用 Grep 在 [entities.yaml](https://link.gitcode.com/i/9e1482e773ca455a9ef82d5071c8e2f3) 中查重（`Grep pattern=" - name: [candidate_name]"`），再呈现汇总：

Registry candidates from this GDD: NEW (not yet registered): - [entity_name] [entity]: [attribute]=[value], [attribute]=[value] - [item_name] [item]: [attribute]=[value], [attribute]=[value] - [formula_name] [formula]: variables=[list], output=[min–max] ALREADY REGISTERED (referenced_by will be updated): - [constant_name] [constant]: value=[N] ← matches registry ✅

【免费下载链接】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