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-StudiosClaude 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则是这份机器可读目录的可视化版本。二、如何阅读流程图符号约定本文所有流程图遵循统一图例看懂它们就能读懂任意一条技能链符号含义──►产生此产物│ ▼流入下一步├──分支多个可能结果×N重复运行 N 次每个系统/故事各一次等(input)技能读取但不产出的文件[optional]门禁通过所必需的可选项WRITE大写立即写入磁盘其中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 plan3.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 如何产出一份可落地的 GDD4.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].md4.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 章节级专家路由该技能不是单会话硬写而是按系统类别路由专家 Agentsystems-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 必须早于 EpicsUX 规格在 Phase 4Pre-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 4Pre-Production而/team-ui属于 Phase 5Production——只有当真正实现 UI 功能时才启动团队编排。/ux-review是/team-ui的HARD gateUX 规格未获批团队编排不允许开始。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 blocker6.2/dev-story的上下文装载与路由机制dev-story 技能实现 是连接规划与代码的枢纽技能。它在动手前强制装载四份上下文缺一即停文件路径缺失时的处理TR 注册表docs/architecture/tr-registry.yamlSTOP——要求先运行/create-epics生成治理 ADR故事头部 ADR 字段指定的文件STOP——要求/architecture-decision补建控制清单docs/architecture/control-manifest.mdWARN 并继续——层规则无法校验引擎偏好.claude/docs/technical-preferences.md决定路由到哪个引擎专家TR 注册表是 GDD 需求的当前真相来源story 内嵌文本可能陈旧以注册表为准治理 ADR 的 Implementation Guidelines 是法律控制清单版本日期与故事内嵌版本不一致时必须先问用户更新故事版本 / 按旧规则实现 / 停下看 diff。依赖故事状态非 Complete 时同样必须先询问继续承担风险 / 停下补依赖 / 修正状态后继续。路由表Phase 3按故事层 类型选择主程序员 AgentFoundation 层一律engine-programmerUI 类型走ui-programmerVisual/Feel 走gameplay-programmerAI/寻路走ai-programmer网络/复制走network-programmerConfig/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.mdConfig/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 check8.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 提供了一个真实的棕地接入会话记录可作为该流程的实战参考。十、常见入口点速查表不知道从哪开始按你的当前位置查表Where you areRun thisBrand new, no idea/start→/brainstormHave a concept, no engine/setup-engineHave concept engine/map-systemsMid-systems design/design-system [next system]or/map-systems nextAll GDDs done/review-all-gdds→/gate-checkIn technical setup/create-architecture→/architecture-decisionStarting UX design/ux-design screen [name]or/ux-design hudScaffolding tests/test-setup→/test-helpersHave stories, ready to code/story-readiness [story]→/dev-story [story]Story done/story-done [story]Running QA for a sprint/qa-plan→/smoke-check→/regression-suiteBug backlog needs sorting/bug-triageExtended stability testing/soak-testNot sure/helpExisting project/adopt十一、在仓库中继续深挖从流程图到实现流程图是地图.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考