企业官网建设流程全解析

使用 CCGS/content-audit技能：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

/content-audit是 Claude Code Game Studios（CCGS）技能体系analysis类别中的一项只读分析技能：它读取design/gdd/下的全部游戏设计文档（GDD），将其中声明的敌人、道具、关卡等内容项与assets/资源目录逐一比对，产出一张“内容类型 → 规格数量 → 已找到数量 → 缺失项”的缺口表，并给出 COMPLETE、GAPS FOUND 或 MISSING CRITICAL CONTENT 三种判定。读完本文，你将掌握该技能的完整行为规格、5 个可复现的测试用例（含 fixture 与断言），以及它与/asset-audit、/design-system等相邻技能的边界与协作方式。

一、技能定位：设计承诺与资源现实的核对器

在 CCGS 的流程体系中，游戏内容从设计到落地要经历“GDD 定义 → 资源制作 → 代码实现”的链条。/content-audit恰好站在设计与生产的交界处，回答一个最朴素也最容易遗漏的问题：文档里承诺要做的东西，资源库里真的有了吗？

依据 content-audit.md 的 Skill Summary，该技能的核心行为是：

1. 读取design/gdd/下所有 GDD 中指定的内容项（enemies、items、levels 等）；
2. 扫描assets/，逐一核对每个内容项是否已有对应资源；
3. 产出缺口表（gap table）：Content Type → Specified Count → Found Count → Missing Items；
4. 给出三选一判定：COMPLETE（全部齐备）、GAPS FOUND（存在缺口）、MISSING CRITICAL CONTENT（关键内容缺失）。

该技能有两条硬性纪律：

• 不触发任何 director gate——它是只读分析技能，不进入创作/技术总监的评审链（见文档 Director Gate Checks 一节：None. Content audit is a read-only analysis skill; no gates are invoked.）；
• 未经用户批准绝不写入文件——技能可以生成缺口表、甚至在用户要求下生成审计报告，但任何写入都必须先征得同意，且不会改动assets/中任何资源文件。

这条纪律与quality-rubric.md中analysis类别的评分标准完全吻合：quality-rubric.md 的 AN1–AN4 要求分析技能“分析阶段只用 Read/Glob/Grep 工具（AN1）、输出结构化发现表（AN2）、任何建议写入都要经过 May I write（AN3）、分析期间不生成 director gate（AN4）”。/content-audit正是按这套标准设计的分析类技能。

二、结构约束：/skill-test static会校验什么

与所有技能一样，/content-audit要能通过 CCGS 测试框架的静态断言（Static Assertions）——这部分由/skill-test static自动验证，无需任何 fixture。依据 skill-test.md，静态模式会逐一检查技能文件的 7 项结构要求。对应到本技能：

注意这里的细微差别：静态断言要求content-audit的技能正文不把 "May I write" 当作默认流程语言，因为它的默认输出（缺口表）是只读的；只有当用户要求生成审计报告时，才进入需要授权的写入流程。这与/skill-test自身的“所有模式只读、不写任何文件”约束（见 skill-test.md 的 Protocol Compliance）属于同类设计。

三、Director Gate 检查：为什么这个技能“无门可过”

/content-audit的 Director Gate Checks 一节只有一句话：None. Content audit is a read-only analysis skill; no gates are invoked.

这在 CCGS 的门控体系里是刻意为之。对照 quality-rubric.md 中gate类别的 G1–G5 指标可以看到，会触发 director gate 的是像/gate-check那样控制阶段流转的技能（full 模式并行唤起 4 个 Tier-1 总监、lean 模式只跑 PHASE-GATE、solo 模式全部跳过）。而analysis类技能的定位是“扫描项目、把发现交给人类审阅”——机械化的资产盘点不涉及创意方向或技术架构裁决，因此：

• 无论production/session-state/review-mode.txt里的评审模式是full、lean还是solo，/content-audit都不会生成任何 CD-/TD-/PR-/AD- 前缀的门控；
• 缺口表是给“人”看的决策输入，而不是自动进入下一阶段的凭证；
• 需要进一步治理时，技能会建议人类另行咨询相应角色（例如美术侧问题建议找 Technical Artist，见下文 Case 5）。

同类只读分析技能如/consistency-check（扫描 GDD 内部冲突）也在其测试规格中明确写有“不读 review-mode.txt、不生成任何 gate 条目”，可视为 analysis 类的共同范式（见 consistency-check.md 的 Case 5）。

四、测试用例全解：5 个场景的 fixture 与断言

测试规格是本文档的主体。以下 5 个用例覆盖了正常路径、缺口路径、无规格路径、格式边界路径与门控合规路径，每个用例都可以在测试框架中作为/skill-test spec content-audit的评估输入。

Case 1：Happy Path —— 所有规格内容均已就位

Fixture：

• design/gdd/enemies.md规格化 4 种敌人类型：Grunt、Sniper、Tank、Boss；
• assets/art/characters/下存在文件夹：grunt/、sniper/、tank/、boss/；
• design/gdd/items.md规格化 3 种道具类型，且 3 种都在assets/data/items/中找到。

输入：/content-audit

期望行为：

1. 技能读取design/gdd/下所有 GDD；
2. 技能对每个规格内容项扫描assets/；
3. 4 种敌人、3 种道具全部找到；
4. 缺口表中所有行的 Found Count = Specified Count，无缺失项；
5. 判定为COMPLETE。

断言：

• 缺口表覆盖 GDD 中出现的所有内容类型；
• 每一行都同时展示 Specified Count 与 Found Count；
• 数量一致时无缺失项；
• 判定为 COMPLETE；
• 不写入任何文件。

这里“不写入任何文件”是 happy path 的收尾断言：即便结果全绿，技能也不会自动落盘报告。

Case 2：Gaps Found —— 敌人类型在资产库中缺失

Fixture：

• design/gdd/enemies.md规格化 3 种敌人：Grunt、Sniper、Boss；
• assets/art/characters/下只有grunt/、sniper/（Boss 文件夹缺失）。

输入：/content-audit

期望行为：

1. 技能读到 3 种规格敌人；
2. 扫描assets/art/characters/只找到 2 种；
3. 缺口表该行显示：Specified 3、Found 2、Missing:Boss；
4. 判定为GAPS FOUND。

断言：

• 缺口表按名称精确定位缺失项 "Boss"；
• Specified Count（3）与 Found Count（2）都展示；
• 只要有任何内容项缺失，判定即为 GAPS FOUND；
• 技能不会假设资源“以后会补上”——它现在就标记出来。这条断言非常关键：审计的职责是如实暴露当前状态，而不是预判未来补做，这正是“缺口表供人决策”定位的体现。

Case 3：无内容规格 —— 给出来源指引

Fixture：

• design/gdd/中只有core-loop.md，且它没有内容清单（content inventory）章节；
• 不存在其他含内容规格的 GDD。

输入：/content-audit

期望行为：

1. 技能读完所有 GDD，发现没有任何内容清单章节；
2. 技能输出引导语："No content specifications found in GDDs — run /design-system first to define content lists"；
3. 不产出缺口表（没有规格，表就没有依据）；
4. 判定为GAPS FOUND（无法在无规格的情况下确认完整性）。

断言：

• 无 GDD 内容规格时不产缺口表；
• 输出建议运行/design-system；
• 判定体现“无法确认完整性”这一事实。

这个用例把“无法验证”与“验证失败”区分开：没有规格书，审计无法给出 COMPLETE，只能如实报告 GAPS FOUND，并指向定义内容清单的上游技能。/design-system是 CCGS 中编写 GDD 的 authoring 技能，GDD 必须包含 8 个必需章节，其中即包含本用例所称的内容规格来源（8 章节要求见 design/CLAUDE.md）。

Case 4：边界情况 —— 资源格式与目标平台不符

Fixture：

• design/gdd/audio.md规格化音频资源为 OGG 格式；
• assets/audio/sfx/jump.wav存在（WAV 格式，非OGG）；
• assets/audio/sfx/land.ogg存在（格式正确）；
• technical-preferences.md规定音频格式为 OGG。

输入：/content-audit

期望行为：

1. 技能读取 GDD 音频规格与技术偏好中的格式要求；
2. 发现jump.wav——按名称存在，但格式错误；
3. 缺口表音频行：Specified 2、Found 2（按名称），但jump.wav被标记为FORMAT ISSUE；
4. 判定为GAPS FOUND（格式合规是内容完整性的组成部分）。

断言：

• 当 GDD 或技术偏好中指定了格式时，技能会对照检查资产格式；
• jump.wav标记为 FORMAT ISSUE，并注明期望格式（OGG）；
• 格式问题与缺失内容在缺口表中是两类不同标记（FORMAT ISSUE ≠ Missing Items）；
• 存在格式问题时判定为 GAPS FOUND。

这里引出了内容审计的横向扩展：文件“在不在”是第一层问题，“对不对”（格式、规格）是第二层问题。technical-preferences.md在 CLAUDE.md 中被定义为项目的技术偏好文件（命名约定、格式、尺寸预算等均在其中），是本用例格式核对的事实依据。

Case 5：门控合规 —— 只读、无 gate、缺口表供人工审阅

Fixture：

• GDD 规格化 10 个内容项，资产库找到 9 个，1 个缺失；
• review-mode.txt内容为full。

输入：/content-audit

期望行为：

1. 技能读取 GDD 并扫描资产，产出缺口表；
2. 无论 review mode 是什么，都不调用任何 director gate；
3. 技能把缺口表作为只读输出呈现给用户；
4. 判定为GAPS FOUND；
5. 技能提出“可以帮你写一份审计报告”，但不会自动写。

断言：

• 任何评审模式下都不调用 director gate；
• 缺口表在不自动写任何文件的前提下呈现；
• 可选报告写入是“提供”而非“强制”；
• 技能不修改任何资产文件。

此用例把前文两条硬性纪律（无 gate、需批准才写）在full评审模式下做了最终验证，确认评审模式对本技能零影响。

五、Protocol Compliance：合规清单

测试规格末尾的协议合规清单，是对技能运行过程的约束汇总：

• 产出缺口表之前，先读取 GDD 与资产目录；
• 缺口表列必须为：Content Type、Specified Count、Found Count、Missing Items；
• 未经用户明确批准不写文件；
• 不调用任何 director gate；
• 判定只能是 COMPLETE、GAPS FOUND、MISSING CRITICAL CONTENT 三者之一。

结合 5 个用例的断言，这套协议保证了content-audit是一个“可预测、可复现、可审阅”的检查工具：同样的仓库状态，无论谁运行、何时运行，都会得到同样的表与同样的判定。

六、Coverage Notes：测试覆盖边界与延伸判定

文档在 Coverage Notes 中如实声明了两处未显式测试的边界：

1. MISSING CRITICAL CONTENT 判定的触发条件：当缺失项在 GDD 中被标记为critical（关键内容）时，判定应从 GAPS FOUND 升级为 MISSING CRITICAL CONTENT。文档明确指出这一点“没有被显式测试，但走的是同一条检测路径”——即缺失检测逻辑一致，只是判级规则不同。这是阅读本文档时最容易踩的坑：不要把 GAPS FOUND 误认为唯一失败态。
2. assets/目录完全不存在的情况：未测试。文档给出的预期是：此时所有规格内容项都会被判定为缺失，产出MISSING CRITICAL CONTENT。

这两条注释的价值在于：测试规格描述的是已证实的当前行为，而 Coverage Notes 划定了“未证实但按代码路径可推断”的区域。按照 CLAUDE.md 对测试框架的说明，本目录中的规格描述的是技能当前行为而非理想行为，如果实测技能行为与规格不符，应先修正技能、再更新规格，并把规格失败当作“需要调查”的信号而非“技能就是错的”的定论。

七、与相邻技能的边界：/content-auditvs/asset-audit

/content-audit极易与同为 analysis 类的/asset-audit混淆，二者的差异在各自的测试规格中讲得很清楚：

asset-audit.md 的 Coverage Notes 明确说明了两者的关系：两者都会检查 GDD 引用与资源库的对应关系，这种重叠是有意为之——/asset-audit侧重“合规”（东西对不对、合不合规范），/content-audit侧重“完整”（东西齐不齐、承诺是否兑现）。实际项目中，先跑/content-audit确认“该有的都有”，再跑/asset-audit确认“有的都对”，是一条完整的内容质量检查链路。在 README.md 的 Slash Commands 清单中，二者同属 “Reviews & Analysis / Art & Assets” 的命令族。

八、在实际项目中的使用方式

/content-audit在 CCGS 项目（或任何按该框架组织的游戏项目）中的推荐使用节奏：

1. 内容齐备性检查：在美术/音频资源批量导入后、进入关卡搭建或里程碑评审前运行，第一时间暴露“设计已定、资源未做”的缺口；
2. 与流程上游配合：若输出 “No content specifications found”，先运行/design-system补齐 GDD 内容清单章节，再重跑审计；
3. 与流程下游配合：缺口表确认后，由生产流程（/create-epics、/create-stories）把“补齐缺失资源”拆成可跟踪的开发任务，或建议对应角色介入（如美术资源问题咨询 Technical Artist）；
4. 关键内容标记：在 GDD 中将直接影响可玩性的内容项标记为 critical，使审计能升级到 MISSING CRITICAL CONTENT 判级，避免发布前才发现关键敌人/关卡缺失。

由于技能默认只读，运行它不会改变仓库状态，可以放心地在任何时间点反复执行；只有当你想留存审计记录时，才需要批准它写入审计报告文件。

九、小结

/content-audit的测试规格展示了 CCGS 技能质量体系的完整范式：一条清晰的行为摘要（读什么、比什么、出什么）→ 一组可机器校验的静态断言 → 一个明确的门控声明（无 gate）→ 五个覆盖正常/缺口/无源/边界/门控的测试用例 → 一份协议合规清单 → 一段诚实的覆盖边界说明。这套规格既是技能的验收标准，也是技能的活文档——任何对这个“GDD 承诺 vs 资产现实”核对器行为有疑问的人，都可以从本文档得到可执行的答案。

延伸阅读：

• 技能注册信息（category:analysis、priority:low）：catalog.yaml
• 分析类技能的统一评分标准 AN1–AN4：quality-rubric.md
• 相邻技能/asset-audit的合规审计规格：asset-audit.md
• GDD 写作规范（含 8 个必需章节）：design/CLAUDE.md
• 技能测试框架运行说明（/skill-test的 static/spec/audit/category 模式）：skill-test.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