企业官网建设流程全解析

Claude Code Game Studios /quick-design：为4小时以内的小功能写三段式轻量设计规格，超范围时如何被重定向到 /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

你在用 Claude Code Game Studios 做游戏项目时，会遇到一类尴尬的需求：改动太小，写一份完整 8 节 GDD 太重；但直接动手又缺少书面依据。/quick-design就是为这类场景准备的轻量设计路径——它针对约 4 小时以内实现量的小改动生成一份 Quick Design Spec，并在你描述的需求超出适用范围时明确拒绝执行、把你重定向到完整的/design-system流程。本文给出从判断适用范围、发起命令、审批落盘到验证结果，以及观察重定向行为的完整操作路径。

前提：会话环境与技能可用性

按 README 的要求准备环境：

1. 安装 Git 和 Claude Code（npm install -g @anthropic-ai/claude-code），推荐安装 jq（hook 校验用）和 Python 3（JSON 校验用）；缺少可选工具时 hooks 会优雅降级，不会阻断。
2. 克隆仓库或使用模板作为项目根目录，进入后启动会话：

git clone https://github.com/Donchitos/Claude-Code-Game-Studios.git my-game cd my-game claude

3. /quick-design是 Game Design 分组的 slash command，在 Claude Code 会话中输入/即可调用。技能本身的定义在 .claude/skills/quick-design/SKILL.md，frontmatter 中argument-hint为[brief description of the change]，allowed-tools为Read, Glob, Grep, Write, Edit——它只读写文件，不执行构建或测试命令。

先判断改动是否属于 quick-design 的范围

技能的第一步是"分类改动"（SKILL.md 第 1 节），只有落入以下四类才走轻量路径：

只要命中以下任一条件，技能应当停下来重定向到/design-system：引入带显著跨系统依赖的新系统、实现量超过一周、或根本性改变既有系统的核心规则。技能会先向你展示分类结论并确认后再继续；不提供参数时，它会请你描述改动而不是擅自选一个功能名。

执行：发起命令并走完审批流程

在会话中执行：

/quick-design "add 10% damage bonus for flanking attacks"

（引号内是你的改动描述；这个措辞来自 docs/WORKFLOW-GUIDE.md 中"Step 2.3: Small Changes Without Full GDDs"给出的示例，该文档同时说明/quick-design用于 tuning、数字调整和小型新增，命令表中标注其处于 Phase 2+。）

接下来按 SKILL.md 的流程会发生四件事：

1. 分类确认。技能给出 Tuning / Tweak / Addition / New Small System 之一的分类，等你确认。如果改动不落入任何一类，技能在此处停止并建议改用/design-system。
2. 上下文扫描。技能读取相关上下文并汇报结果：在design/gdd/中找最相关的 GDD 并读取受影响的章节；检查design/gdd/systems-index.md是否存在（不存在时记录 "No systems index found — skipping dependency tier check."）；检查design/quick-specs/中是否已有触碰过该系统的 quick spec 以避免冲突；若是 Tuning 类，还会查assets/data/中持有相关数值的数据文件。汇报形如 "Found GDD at [path]. Relevant section: [section name]. No conflicting quick specs found."。
3. 起草规格。技能按改动类别套对应的规格模板：
   • Tuning：一张变更表（Parameter / Old Value / New Value / Rationale）+ Tuning Knob Mapping（核对新值落在 GDD 记录的数值区间内、边缘还是区间外，区间外需说明理由）+ Acceptance Criteria。
   • Tweak / Addition：Change Summary、Motivation、Design Delta（原文引用 GDD 规则段落，再给出等精度改写）、New Rules / Values、Affected Systems 影响表、Acceptance Criteria、GDD Update Required? 标记。
   • New Small System：精简版 GDD 结构（Overview、Core Rules、Tuning Knobs 表、Acceptance Criteria、Systems Index 归属说明），数值一律要求放进assets/data/[appropriate-file].json而非硬编码。
4. 审批落盘。技能完整展示草稿后询问：

May I write this Quick Design Spec to `design/quick-specs/[kebab-case-title]-[YYYY-MM-DD].md`?

你批准后，技能在design/quick-specs/不存在时创建目录并写入文件；文件名用 kebab-case 标题加当天日期，文档给出的示例是jump-height-tuning-2026-03-10、parry-window-addition-2026-03-10。若规格中标记了 GDD 需要更新，技能会在写完 quick spec 后单独再问一次，并先展示要改的确切文本（旧 vs 新）——未经明确批准不会动design/gdd/下的任何文件。

验证：文件、交接输出与 verdict

落盘后技能输出交接块（以下为 SKILL.md 第 5 节的模板，方括号内容由技能按实际填写，非固定日志）：

Quick Design Spec written to: design/quick-specs/[filename].md Type: [Tuning / Tweak / Addition / New Small System] System: [system name] GDD update: [Required — pending approval / Applied / Not required] Next step: This spec is ready for `/story-readiness` validation before implementation. Reference this spec in the story's GDD Reference field.

你可以按以下三点核对结果：

• 目标路径下存在对应文件，且文件内包含与类别匹配的结构和可测试的 Acceptance Criteria（Tuning 类的验收项直接指向assets/data/[file]中参数读到的新值）。
• 交接块中 Type、System 与你的分类确认一致；若涉及 GDD 更新，其状态应为 "Required — pending approval"（等待你二次批准）而非未标记。
• Pipeline 说明：Quick Design Spec 按设计绕过/design-review和/review-all-gdds，适用于小、低风险、边界清晰的改动，不需要等待 director 评审。

超范围时的重定向行为

当你描述的需求超出轻量范围时，技能不应写文件，而是明确指向完整流程。触发重定向的条件（SKILL.md "Pipeline Notes"）包括：改动新增了应进 systems index 的系统、显著改变跨系统行为或系统间契约、引入影响游戏 MDA aesthetic 平衡的新玩家机制、实现量预计超过一周。SKILL.md 给出的重定向措辞是：

This change has grown beyond quick-spec scope. I recommend using `/design-system` to author a full GDD for this.

测试框架对这一路径有独立的规格断言（见 CCGS Skill Testing Framework/skills/authoring/quick-design.md 的 Case 2）：技能在起草之前就要检测到范围超限并停止，消息中必须点名/design-system作为替代方案（示例措辞："This feature is too large for a quick-design. Use/design-system [name]for a full GDD."），且不产生任何 quick spec 文件，verdict 记为 REDIRECTED（而非 CREATED 或 BLOCKED）。测试该路径时的典型输入如 "redesign the entire combat system" 或 "new progression mechanic affecting all classes"。

判定结果可以直接落到操作上的区别：看到/design-system提示且design/quick-specs/（或测试规格所述的design/quick-notes/）没有新文件，重定向就按预期发生了；此时下一步就是运行/design-system [system-name]走完整 8 节 GDD 流程，不要再尝试把同一需求硬塞回 quick-design。

边界、冲突与注意事项

• 两处文档对"三段式"的表述存在冲突，需按实际安装的文件为准：测试框架规格描述的 quick-design 产出是 Overview、Rules、Acceptance Criteria 三个固定小节，输出路径为design/quick-notes/[name].md，verdict 词表为 CREATED / BLOCKED / REDIRECTED；而仓库内实际交付的技能 .claude/skills/quick-design/SKILL.md 按改动类别使用四套模板（Tuning 表格 / Tweak-Addition 规格 / 精简 GDD），输出路径为design/quick-specs/[name]-[date].md，verdict 为 COMPLETE，交接指向/story-readiness。两者都支持"约 4 小时以内"的范围判断和"超范围重定向到/design-system"，但格式与路径不一致。本文以实际交付的 SKILL.md 为执行路径，核对结果时请对照你工作区中这份文件。
• 无参数调用：不带参数运行/quick-design时，技能应输出用法错误而不是猜测功能名。测试规格记录的预期是 "No feature name specified. Usage: /quick-design [feature-name]" 并附示例/quick-design pause-menu-settings，且不创建任何文件。
• 已有同名规格：测试规格 Case 3 要求技能先读取已存在的 quick note，然后询问 "Update it, or create a new version?"，由你选择更新或新建，且覆盖前仍须再次经过 "May I write" 批准，不会自动覆写。
• 评审模式不影响本技能：测试规格 Case 5 明确断言 quick-design 不读取production/session-state/review-mode.txt、不派生任何 director gate 代理（无 CD-、TD-、PR-、AD- 前缀的 gate），即使 review mode 设为full行为也不变——轻量技能不设评审门禁是有意设计。
• 范围升级：如果实现过程中发现改动比预期大，SKILL.md 的 Recommended Next Steps 给出的路径是运行/design-system [system-name]改走完整 GDD。

落盘之后的下一步

规格写完后，SKILL.md 给出的后续操作是：

• 运行/story-readiness [story-path]在实现前校验 story，并在 story 的 GDD Reference 字段引用这份 quick spec；
• 校验通过后运行/dev-story [story-path]开始实现；
• 若改动变大，运行/design-system [system-name]改走完整 GDD。

也就是说，quick spec 的终点不是"写完即止"，而是作为 story 的 GDD 引用来源进入既有实现管线。

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