CCGS 技能流程图全解析：72 个工作流技能如何衔接 7 个游戏开发阶段

CCGS 技能流程图全解析：72 个工作流技能如何衔接 7 个游戏开发阶段

【免费下载链接】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）以 49 个 Agent、72 个 Slash Command 技能构成一套完整的"AI 游戏工作室"编排系统。本文以仓库中的 skill-flow-diagrams.md 为骨架，逐层拆解这些技能在 7 个开发阶段（Concept → Systems Design → Technical Setup → Pre-Production → Production → Polish → Release）中的调用顺序、前后依赖与产物流转关系，并结合.claude/skills/下的真实技能实现与 workflow-catalog.yaml 中的阶段定义，讲清"哪个技能在什么时机运行、产出什么文件、读入什么输入、由谁把关"。读完本文，你将能像查地图一样在任何项目节点上找到下一步该运行的技能，并理解门禁（Gate）判定机制背后的完整证据链。

一、为什么需要"技能流程图"：72 个技能不是随机菜单

CCGS 的 72 个技能分布在.claude/skills/下，覆盖从/brainstorm（头脑风暴）到/hotfix（紧急热修复）的完整生命周期。如果把它们当作平铺的"指令菜单"随意调用，就会丢失最重要的东西——顺序与产物：GDD 没写完就写故事、ADR 还是 Proposed 就实现代码、没有 Vertical Slice 就进入 Production，这些都会造成返工。

技能流程图存在的意义，就是把技能之间的三条隐式关系显式化：

• 先后关系：每个技能运行前需要哪些产物（输入），运行后产出哪些文件（输出）；
• 依赖关系：哪个技能必须在前（如/ux-design必须先于/create-epics，否则故事验收标准无法引用 UX 产物）；
• 门禁关系：每个阶段以/gate-check收口，产物的"存在性 + 质量"共同决定能否进入下一阶段。

仓库中的权威阶段序列定义在 .claude/docs/workflow-catalog.yaml，由/help读取，用于实时判断"你现在在哪、下一步该做什么"。流程图（docs/examples/skill-flow-diagrams.md）则是这份机器可读目录的可视化版本。

二、如何阅读流程图：符号约定

本文所有流程图遵循统一图例，看懂它们就能读懂任意一条技能链：

其中"WRITE（立即写入）"是最关键的设计：文档主流程强调/design-system的每个章节在获得批准后立刻写入文件，而不是等全部讨论完再一次写。这正是 design-system 技能实现 中"增量写入（incremental writes）"与"会话中断恢复"机制的基础——每一节都独立落盘，任何一次崩溃、压缩或断线都不会丢失已批准的设计成果。

三、全景图：从零到上线的完整流水线（Zero to Ship）

这是整个编排系统的主干视图，7 个阶段依次推进，每个阶段结尾都有一个/gate-check门禁：

PHASE 1: CONCEPT /start ──────────────────────────────────────────────────────► routes to A/B/C/D /brainstorm ──────────────────────────────────────────────────► design/gdd/game-concept.md /setup-engine ────────────────────────────────────────────────► CLAUDE.md + technical-preferences.md /design-review [game-concept.md] ────────────────────────────► concept validated /gate-check ─────────────────────────────────────────────────► PASS → advance to systems-design │ ▼ PHASE 2: SYSTEMS DESIGN /map-systems ────────────────────────────────────────────────► design/gdd/systems-index.md │ ▼ (for each system, in dependency order) /design-system [name] ──────────────────────────────────────► design/gdd/[system].md /design-review [system].md ─────────────────────────────────► per-GDD review comments │ ▼ (after all MVP GDDs done) /review-all-gdds ────────────────────────────────────────────► design/gdd/gdd-cross-review-[date].md /gate-check ─────────────────────────────────────────────────► PASS → advance to technical-setup │ ▼ PHASE 3: TECHNICAL SETUP /create-architecture ────────────────────────────────────────► docs/architecture/master.md /architecture-decision (×N) ─────────────────────────────────► docs/architecture/[adr-nnn].md /architecture-review ────────────────────────────────────────► review report + docs/architecture/tr-registry.yaml /create-control-manifest ────────────────────────────────────► docs/architecture/control-manifest.md /gate-check ─────────────────────────────────────────────────► PASS → advance to pre-production │ ▼ PHASE 4: PRE-PRODUCTION [UX — before epics, so specs exist when stories are written] /ux-design [screen/hud/patterns] ────────────────────────────► design/ux/*.md /ux-review ──────────────────────────────────────────────────► UX specs approved (HARD gate for /team-ui) [Test infrastructure — scaffold before stories reference tests] /test-setup ─────────────────────────────────────────────────► test framework + CI/CD pipeline /test-helpers ───────────────────────────────────────────────► tests/helpers/[engine-specific].gd [Stories + prototype] /create-epics [layer] ───────────────────────────────────────► production/epics/*/EPIC.md /create-stories [epic-slug] ─────────────────────────────────► production/epics/*/story-*.md /prototype [core-mechanic] ──────────────────────────────────► prototypes/[name]/ /playtest-report ────────────────────────────────────────────► tests/playtest/vertical-slice.md /sprint-plan new ────────────────────────────────────────────► production/sprints/sprint-01.md /gate-check ─────────────────────────────────────────────────► PASS → advance to production │ ▼ PHASE 5: PRODUCTION (repeating sprint loop) /sprint-status ──────────────────────────────────────────────► sprint snapshot /story-readiness [story] ────────────────────────────────────► story validated READY │ ▼ (pick up and implement) /dev-story [story] ──────────────────────────────────────────► routes to correct programmer agent │ ▼ (during implementation, as needed) /code-review ────────────────────────────────────────────────► code review report /scope-check ────────────────────────────────────────────────► scope creep detected / clear /content-audit ──────────────────────────────────────────────► GDD content gaps identified /bug-report ─────────────────────────────────────────────────► production/qa/bugs/bug-NNN.md /bug-triage ─────────────────────────────────────────────────► bugs re-prioritized + assigned [Team skills for feature areas — spawn when working a full feature] /team-combat / /team-narrative / /team-ui / /team-level / /team-audio [QA cycle per sprint] /qa-plan ────────────────────────────────────────────────────► production/qa/qa-plan-sprint-NN.md /smoke-check ────────────────────────────────────────────────► smoke test gate (PASS/FAIL) /regression-suite ───────────────────────────────────────────► coverage gaps + missing regression tests /test-evidence-review ───────────────────────────────────────► evidence quality report /test-flakiness ─────────────────────────────────────────────► flaky test report │ ▼ /story-done [story] ─────────────────────────────────────────► story closed + next surfaced /sprint-plan [next] ─────────────────────────────────────────► next sprint │ ▼ (after Production milestone) /milestone-review ───────────────────────────────────────────► milestone report /gate-check ─────────────────────────────────────────────────► PASS → advance to polish │ ▼ PHASE 6: POLISH /perf-profile ───────────────────────────────────────────────► perf report + fixes /balance-check ──────────────────────────────────────────────► balance report + fixes /asset-audit ────────────────────────────────────────────────► asset compliance report /tech-debt ──────────────────────────────────────────────────► docs/tech-debt-register.md /soak-test ──────────────────────────────────────────────────► soak test protocol + results /localize ───────────────────────────────────────────────────► localization readiness report /team-polish ────────────────────────────────────────────────► polish sprint orchestrated /team-qa ────────────────────────────────────────────────────► full QA cycle sign-off /gate-check ─────────────────────────────────────────────────► PASS → advance to release │ ▼ PHASE 7: RELEASE /launch-checklist ───────────────────────────────────────────► launch readiness report /release-checklist ──────────────────────────────────────────► platform-specific checklist /changelog ──────────────────────────────────────────────────► CHANGELOG.md /patch-notes ────────────────────────────────────────────────► player-facing notes /team-release ───────────────────────────────────────────────► release pipeline orchestrated │ ▼ (post-launch, ongoing) /hotfix ─────────────────────────────────────────────────────► emergency fix with audit trail /team-live-ops ──────────────────────────────────────────────► live-ops content plan

3.1 起点/start：四路分流的引导入口

流程图的第一个节点是/start，其实现位于 .claude/skills/start/SKILL.md。它不假设你处在任何阶段，而是按你的现状路由到 A/B/C/D 四条路径之一：

• 路径 A：完全没有想法 → 引导到/brainstorm；
• 路径 B：只有模糊想法 → 带种子话题进入/brainstorm；
• 路径 C：已有清晰概念 → 进入/setup-engine与/map-systems；
• 路径 D1：已有项目但产物稀少 → 走正常流程补齐；
• 路径 D2：已有项目且存在 GDD/ADR → 先运行/project-stage-detect再走/adopt棕地迁移。

这一"问询式"设计贯穿整个框架：所有技能都遵循"提问 → 给选项 → 用户决策"的协作协议，系统绝不替你拍板。

3.2 门禁收口：/gate-check的三态裁决

每个阶段的终点都是/gate-check，其完整实现见 .claude/skills/gate-check/SKILL.md。它输出三种裁决：

• PASS：所有必需产物存在且质量检查通过；
• CONCERNS：存在次要缺口，可在下一阶段内解决；
• FAIL：存在必须先行解决的关键阻塞项。

门禁不只是"文件存在性"检查，还包含质量检查与交叉引用检查，例如 Systems Design → Technical Setup 门禁会验证"所有 MVP 级 GDD 通过/design-review、/review-all-gdds裁决不为 FAIL、系统依赖双向一致、无陈旧 GDD 引用"。Pre-Production → Production 门禁则内置Vertical Slice 硬性校验——只要"真人未在无人指导下玩通核心循环"一项为 FAIL，整体裁决自动 FAIL。裁决通过后，新阶段名被写入production/stage.txt（单行），状态栏随即更新；写入前必须征求用户同意。

值得注意的细节：门禁裁决是建议性的（ADVISORY），它只记录风险、绝不强行阻止用户前进——"Never block a user from advancing"是该技能协作协议的明文约束。

四、技能链详解：/design-system 如何产出一份可落地的 GDD

4.1 输入侧：三份前置产物

systems-index.md (input) game-concept.md (input) upstream GDDs (input, if any) │ ▼ /design-system [name] │ ├── Pre-check: feasibility table + engine risk flags │ ├── Section cycle × 8: │ question → options → decision → draft → approval → WRITE │ [each section written to file immediately after approval] │ └── Output: design/gdd/[system].md (complete, all 8 sections) │ ▼ /design-review design/gdd/[system].md │ ├── APPROVED → mark DONE in systems-index, proceed to next system ├── NEEDS REVISION → agent shows specific issues, re-enter section cycle └── MAJOR REVISION → significant redesign needed before next system │ ▼ (after all MVP GDDs + cross-review) /review-all-gdds │ └── Output: gdd-cross-review-[date].md

4.2 8 个必需章节与"章节循环"

design-system 技能实现 规定 GDD 必须包含 8 个必需章节：Overview、Player Fantasy、Detailed Design/Rules、Formulas、Edge Cases、Dependencies、Tuning Knobs、Acceptance Criteria（模板还附有 Visual/Audio、UI Requirements、Open Questions 可选章节）。每一节都走相同的循环：

Context → Questions → Options → Decision → Draft → Approval → Write

实现细节上有几条强制协议值得注意：

• 草稿与批准控件必须出现在同一条响应中——技能文件明确写道："如果草稿出现而没有控件，用户就被留在空白提示符前，这是协议违规"；
• 写入时old_string必须包含章节标题，因为所有占位符都是相同的[To be designed]，只匹配占位符会导致 Edit 工具匹配不唯一；
• Formulas 章节的完成导向：每个公式必须给出变量表（名称/符号/类型/范围/描述）、输出范围与带真实数字的工作示例，禁止出现"公式待定"或纯文字描述；
• Acceptance Criteria 必须采用 GIVEN-WHEN-THEN 格式，且每条验收标准必须能被 QA 测试员在不读 GDD 的情况下独立验证。

4.3 章节级专家路由

该技能不是单会话硬写，而是按系统类别路由专家 Agent：systems-designer（公式与规则）、economy-designer（经济/消耗曲线）、narrative-director（剧情系统）、qa-lead（验收标准可测性）等。所有专家的产出都回到主会话，由主会话通过AskUserQuestion呈现给用户决策，专家 Agent 不直接写文件。跨系统一致性由design/registry/entities.yaml（实体注册表）保障：章节 C/D 写完后会扫描与注册表冲突的实体名、公式名与数值常量，发现冲突立即浮出而不是静默继续。

4.4 评审与跨 GDD 一致性

单个 GDD 完成后，必须另开新会话运行/design-review（同一会话内评审会继承全部设计历史，丧失独立批判性）。评审裁决为 APPROVED 才在design/gdd/systems-index.md中标记 DONE；全部 MVP GDD 通过后运行/review-all-gdds，输出design/gdd/gdd-cross-review-[date].md，执行依赖双向一致性、规则矛盾、陈旧引用、所有权冲突、公式取值范围兼容性等跨 GDD 检查。

五、技能链详解：UX / UI 流水线

5.1 为什么 UX 必须早于 Epics

UX 规格在 Phase 4（Pre-Production）编写，先于 epic 拆分，这样故事验收标准可以直接引用具体的 UX 产物（屏幕文件而非 GDD 原文）：

design/gdd/*.md (UI/UX requirements extracted) design/player-journey.md (emotional arc, if authored) │ ▼ /ux-design hud → design/ux/hud.md /ux-design screen [name] → design/ux/screens/[name].md /ux-design patterns → design/ux/interaction-patterns.md │ ▼ /ux-review design/ux/ │ ├── APPROVED → UX specs ready, proceed to /create-epics ├── NEEDS REVISION → blocking issues listed → fix → re-run review └── MAJOR REVISION → fundamental UX problems → redesign before epics │ ▼ (after APPROVED — in Phase 5 when implementing UI features) /team-ui │ ├── Phase 1: /ux-design (if any specs still missing) + /ux-review ├── Phase 2: visual design (art-director) ├── Phase 3: layout implementation (ui-programmer) ├── Phase 4: accessibility audit (accessibility-specialist) └── Phase 5: final review

关键约定（流程图明确标注）：/ux-design与/ux-review属于 Phase 4（Pre-Production），而/team-ui属于 Phase 5（Production）——只有当真正实现 UI 功能时才启动团队编排。/ux-review是/team-ui的HARD gate：UX 规格未获批，团队编排不允许开始。

5.2 与门禁的联动

从 workflow-catalog.yaml 的 Pre-Production 阶段定义可以看到，/ux-design是required: true且可重复运行（min_count: 1），/ux-review要求在任何 epic 创建之前运行。门禁还会校验"UX 规格覆盖所有 MVP 级 GDD 的 UI Requirements 章节"，并核验design/accessibility-requirements.md中承诺的无障碍等级是否在关键屏幕规格中落实——这正是"硬门禁"的落地方式。

5.3 遗留参考版本

仓库中另有一份"UX Pipeline in Detail (Legacy Reference)"（docs/examples/skill-flow-diagrams.md 内），结构与此一致，仅标注为历史参考。差异点在于旧版/team-ui的 Phase 1 是"context load +/ux-design"，新版则明确要求先跑/ux-design+/ux-review双技能。

六、技能链详解：开发故事（Dev Story）流程

6.1 从就绪到关闭的完整链路

/story-readiness [story] │ ├── READY → Status: ready-for-dev → pick up for implementation ├── NEEDS WORK → agent shows specific gaps → resolve → re-run readiness └── BLOCKED → ADR still Proposed, or upstream story incomplete │ ▼ (after READY) /dev-story [story] │ ├── Reads: story file, linked GDD requirement, ADR decisions, control manifest ├── Routes to: gameplay-programmer / engine-programmer / ui-programmer / etc. │ └── Implementation begins │ ▼ (optional, during/after implementation) /code-review → architectural review of changeset /scope-check → verify no scope creep vs. original story criteria /test-evidence-review → validate test files and manual evidence quality │ ▼ /story-done [story] │ ├── COMPLETE → Status: Complete, sprint-status.yaml updated, next story surfaced ├── COMPLETE WITH NOTES → complete but some criteria deferred (logged) └── BLOCKED → acceptance criteria cannot be verified → investigate blocker

6.2/dev-story的上下文装载与路由机制

dev-story 技能实现 是"连接规划与代码"的枢纽技能。它在动手前强制装载四份上下文，缺一即停：

TR 注册表是 GDD 需求的当前真相来源（story 内嵌文本可能陈旧，以注册表为准）；治理 ADR 的 Implementation Guidelines 是"法律"；控制清单版本日期与故事内嵌版本不一致时必须先问用户（更新故事版本 / 按旧规则实现 / 停下看 diff）。依赖故事状态非 Complete 时同样必须先询问（继续承担风险 / 停下补依赖 / 修正状态后继续）。

路由表（Phase 3）按故事"层 + 类型"选择主程序员 Agent：Foundation 层一律engine-programmer；UI 类型走ui-programmer；Visual/Feel 走gameplay-programmer；AI/寻路走ai-programmer；网络/复制走network-programmer；Config/Data 类型完全跳过 Agent——直接编辑数据文件。引擎专家（godot/unity/unreal 各专科）作为次位 Agent 在涉及引擎特定 API 或 ADR 标注 HIGH 引擎风险时并行派发。

6.3 测试不是可选项

对 Logic 与 Integration 故事，测试文件必须在实现阶段同步编写（[system]_[feature]_test.[ext]命名、test_[scenario]_[expected_outcome]函数命名、每条验收标准至少一个测试函数、禁止随机种子/时间依赖/外部 IO），否则/story-done无法关闭故事。Visual/Feel 与 UI 故事不写自动化测试，但要求记录人工证据文档（production/qa/evidence/[slug]-evidence.md）；Config/Data 故事以冒烟检查作为证据。

七、技能链详解：故事生命周期（Backlog → Closed）总览

/create-epics [layer] │ └── Output: production/epics/[slug]/EPIC.md │ ▼ /create-stories [epic-slug] │ └── Output: production/epics/[slug]/story-NNN-[slug].md (Status: Ready or Blocked if ADR is Proposed) │ ▼ /story-readiness [story] │ ├── READY → /dev-story → implement → /story-done ├── NEEDS WORK → resolve gaps → re-run └── BLOCKED → fix upstream dependency first

这一链路与 workflow-catalog.yaml 中 Production 阶段的步骤定义一一对应：create-stories的产物规格（globproduction/epics/**/*.md、min_count: 2）直接体现了"每个 epic 至少拆出两个故事"的隐含约定；implement步骤通过/dev-story [story-path]路由到正确的程序员 Agent。故事文件中内嵌 GDD 需求引用（TR-ID，而非引用文本，保证始终新鲜）、ADR 引用（仅 Accepted 状态；Proposed 使故事状态为 Blocked）、控制清单版本日期（用于陈旧检测）、引擎特定实现说明与 GDD 验收标准。

八、技能链详解：QA 流水线

QA 技能链横跨三个阶段，分工明确：

[Phase 4 — one-time infrastructure setup] /test-setup ────────────────────────────────────────────────────► test framework scaffolded + CI/CD wired /test-helpers ──────────────────────────────────────────────────► tests/helpers/[engine].gd (GDUnit4, NUnit, etc.) [Phase 5 — per-sprint QA cycle] /qa-plan [sprint or feature] │ ├── Reads: story files, GDDs, acceptance criteria ├── Classifies each story by test type: │ Logic → automated unit test (BLOCKING) │ Integration → integration test or documented playtest (BLOCKING) │ Visual/Feel → screenshot + lead sign-off (ADVISORY) │ UI → manual walkthrough or interaction test (ADVISORY) │ Config/Data → smoke check (ADVISORY) └── Output: production/qa/qa-plan-sprint-NN.md │ ▼ /smoke-check │ ├── PASS → QA hand-off cleared └── FAIL → block sprint close → fix critical paths first │ ▼ /regression-suite │ └── Coverage gaps + list of fixed bugs without regression tests │ ▼ /test-evidence-review │ └── Validates evidence quality, not just existence │ ▼ (if CI run history available) /test-flakiness │ └── Flaky test report + fix recommendations [Phase 6 — extended stability testing] /soak-test ─────────────────────────────────────────────────────► soak test protocol + observed results /team-qa ───────────────────────────────────────────────────────► full QA cycle sign-off for release gate [Ongoing — bug management] /bug-report ────────────────────────────────────────────────────► production/qa/bugs/bug-NNN.md /bug-triage ────────────────────────────────────────────────────► open bugs re-prioritized + assigned [Meta — harness validation] /skill-test [lint|spec|catalog] ────────────────────────────────► skill file structural + behavioral check

8.1 测试类型的 BLOCKING / ADVISORY 二分法

/qa-plan的核心设计是按故事类型确定证据等级：Logic 与 Integration 故事需要自动化测试或可记录的玩法测试，属于BLOCKING（阻塞冲刺关闭）；Visual/Feel、UI、Config/Data 则以截图 + 主管签核、人工走查、冒烟检查作为ADVISORY（建议性）证据。这与/dev-story的测试强制规则、以及 Production → Polish 门禁中"所有 Logic 故事必须有对应tests/unit/测试文件"的硬性检查完全一致。

8.2 冒烟检查是冲刺关闭的闸门

/smoke-check的 PASS/FAIL 决定 QA 交接是否放行，FAIL 会阻塞冲刺关闭并要求优先修复关键路径。/test-evidence-review与/test-flakiness则进一步把 QA 从"看有没有测试"推进到"看证据质量"与"看 CI 历史中的抖动测试"。

8.3 元层：技能本身也可被测试

QA 链的最后一行/skill-test [lint|spec|catalog]是对技能框架自身的验证，由CCGS Skill Testing Framework/承载：catalog.yaml登记全部 72 技能与 49 Agent 的类别、spec 路径与测试追踪字段；quality-rubric.md定义各类别的通过/失败指标；每个技能的 spec 文件（CCGS Skill Testing Framework/skills/[category]/[name].md）包含 5 个测试用例加协议合规断言。注意 CCGS Skill Testing Framework/CLAUDE.md 中的说明：spec 描述的是当前行为而非理想行为，spec 失败应视为"需要调查"，而非"技能绝对错了"。

九、棕地接入流程：现有项目如何上车

对已有代码与文档的项目，不必从零开始，直接运行/adopt（或走/start的 D2 路径）：

/project-stage-detect → stage detection report │ ▼ /adopt │ ├── Phase 1: detect what exists ├── Phase 2: FORMAT audit (not just existence) ├── Phase 3: classify gaps (BLOCKING / HIGH / MEDIUM / LOW) ├── Phase 4: ordered migration plan ├── Phase 5: write docs/adoption-plan-[date].md └── Phase 6: fix most urgent gap inline (optional) │ ▼ /design-system retrofit [path] → fills missing GDD sections /architecture-decision retrofit [path] → fills missing ADR sections /gate-check → where are you in the pipeline?

两个要点：

• "格式审计"而非"存在性审计"：adopt 的 Phase 2 明确要求检查文档是否符合框架格式，而不只是"文件在不在"；
• Retrofit 模式只补缺不覆盖：/design-system retrofit与/architecture-decision retrofit会扫描现有文件中缺失的章节，仅填充缺失或占位内容，绝不覆盖已有内容。这一行为在 design-system 技能实现 的第 1 阶段有完整定义（识别 8 个必需章节中哪些存在、哪些只是[To be designed]占位，并在动手前先向用户展示将触及/不触及的清单）。

仓库中的 docs/examples/session-adopt-brownfield.md 提供了一个真实的棕地接入会话记录，可作为该流程的实战参考。

十、常见入口点速查表

不知道从哪开始？按你的当前位置查表：

十一、在仓库中继续深挖：从流程图到实现

流程图是地图，.claude/skills/下的技能文件是每个地点的详细攻略。以下路径可供你按需深入：

• 阶段权威定义：.claude/docs/workflow-catalog.yaml——7 阶段、每阶段的步骤清单、产物 glob 与 required/repeatable 标记；
• 门禁实现：.claude/skills/gate-check/SKILL.md——6 道门禁的完整产物清单、质量检查、导演小组（Director Panel）并行评估与 Chain-of-Verification 自检；
• GDD 编写：.claude/skills/design-system/SKILL.md——8 章节循环、专家路由表、实体注册表冲突检测、retrofit 模式；
• 故事实现：.claude/skills/dev-story/SKILL.md——上下文装载清单、程序员路由表、测试强制规则、错误恢复协议；
• 完整工作流手册：docs/WORKFLOW-GUIDE.md——每个阶段的逐步操作指南与目录结构约定；
• 会话实录：docs/examples/下的 session-design-crafting-system.md、session-implement-combat-damage.md、session-gate-check-phase-transition.md 等，展示了/design-system、/dev-story、/gate-check在真实会话中的运行形态；
• 技能框架自身验证：CCGS Skill Testing Framework/catalog.yaml 与 CCGS Skill Testing Framework/quality-rubric.md——如何用/skill-test对技能文件做结构与行为检查。

掌握这套流程图后，你就能把 CCGS 从"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