Claude Code Game Studios /consistency-check：扫描多份GDD找出公式冲突、归属竞争与依赖缺口

Claude Code Game Studios /consistency-check扫描多份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在 Claude Code Game StudiosCCGS工作流中游戏设计文档GDD由多个系统分头编写战斗 GDD 定义了伤害公式物品掉落写在掉落表里经济 GDD 又引用了同一批数值。随着design/gdd/下的 GDD 越来越多同一实体在不同文档里出现不同属性、同一个公式在不同 GDD 中变量不一致、某份 GDD 引用了根本不存在的系统这类跨文档问题很难靠人眼发现。/consistency-check就是为解决这个问题设计的技能它把design/gdd/下的所有系统 GDD 与实体注册表design/registry/entities.yaml交叉比对找出公式冲突、归属竞争两个 GDD 争抢同一事实的所有权与依赖缺口引用了没有 GDD 的系统输出一份结构化冲突报告。该技能在分析阶段是只读的任何写操作修正注册表都会先征求你的批准。前提跑扫描之前需要什么有两项前置条件缺了扫描要么停止、要么无意义GDD 已就位。系统 GDD 放在design/gdd/下命名规范为[system-slug].md如combat-system.md。按 design/CLAUDE.md 的要求每份 GDD 需包含 8 个必需小节Overview、Player Fantasy、Detailed Rules、Formulas、Edge Cases、Dependencies、Tuning Knobs、Acceptance Criteria。其中game-concept.md、systems-index.md、game-pillars.md不属于系统 GDD会被扫描排除。注册表非空。entities.yaml 是跨文档事实的单一可信来源由/design-system在每份 GDD 完成写入后自动填充。技能启动时会加载该文件如果文件不存在或没有任何条目它会直接停止并提示Entity registry is empty. Run /design-system to write GDDs — the registry is populated automatically after each GDD is completed. Nothing to check yet.此时没有可检查的内容正确动作是先运行/design-system产出 GDD 并填充注册表。仓库模板里这份文件默认是空列表entities: []等并附有 goblin、goblin_arm、damage_formula、gold_carry_limit 等示例条目说明四类条目entities / items / formulas / constants的字段格式。选择扫描范围技能的 argument-hint 是[full | since-last-review | entity:name | item:name]四种模式对应不同场景模式写法适用时机全量/consistency-check或/consistency-check full首次基线检查/review-all-gdds之前增量/consistency-check since-last-review日常检查只看上次 review 报告之后改过的 GDD单实体/consistency-check entity:goblin只查一个实体在所有 GDD 中的一致性单物品/consistency-check item:item名只查一个物品售价、重量、堆叠规则等name需要替换为注册表里已注册的名字例如实体示例条目用的是goblin。按 SKILL.md 给出的建议推荐运行时机是每写完一份新 GDD 就查一次不要攒到架构阶段才查、跑/review-all-gdds之前先查一遍保证基线干净、跑/create-architecture之前查不一致会污染下游 ADR。扫描机制grep 优先不做全文阅读技能加载注册表后会建立四张查找表entity_map、item_map、formula_map、constant_map然后打印一行加载报告Registry loaded: [N] entities, [N] items, [N] formulas, [N] constants Scope: [full | since-last-review | entity:name]随后用 globdesign/gdd/*.md列出范围内的 GDD 并先报告清单再对每个注册条目按名字在各 GDD 中做定向 grep只取命中行及前后 3 行上下文而不是把每份 GDD 全文读一遍。SKILL.md 中给出的量级对比是与其读 10 份 GDD × 各 400 行4000 行不如 grep 50 个实体名 × 10 份 GDD50 次定向搜索每次命中约返回 10 行。since-last-review模式内部用下面这条 git 命令找出改过的 GDD并限定为最近一份design/gdd/gdd-cross-review-*.md报告创建日期之后修改的文件git log --name-only --prettyformat: -- design/gdd/ | grep \.md$ | sort -u四类扫描的判定规则实体扫描GDD 中实体某属性值 ≠ 注册表值 → CONFLICTGDD 提到了实体但没写可比属性 → NOTE不可验证不算冲突。物品扫描比对售价/金值、重量、堆叠规则、分类。公式扫描公式名附近出现的变量名不同 → CONFLICT输出区间/上限表述不同 → CONFLICT。常量扫描常量名附近出现的数字与注册表不同 → CONFLICT。Phase 3 之后只有命中冲突的条目才会触发针对性深读技能会读取冲突 GDD 的完整相关章节确认冲突并回答三个问题——哪份 GDD 是对的以注册表source:字段为准、注册表本身是否过期source GDD 是否晚于注册表条目被改过、还是这本来就是一次有意的设计变更若是正确路径是更新 source GDD → 更新注册表 → 再修其余 GDD。标题里的三类问题分别怎么判公式冲突。对应公式扫描同一个公式名在不同 GDD 中出现不同的变量集合或不同的输出区间。例如测试规范 consistency-check.md 里的用例GDD-A 写damage attack * 1.5GDD-B 对同一实体类型写damage attack * 2.0两者都引用同一个attack变量——这就是典型的公式冲突规范中记为 Formula Mismatch、严重度 HIGH且要求报告里同时展示两条冲突公式而不是只写一句“存在公式冲突”。归属竞争。两份 GDD 声称拥有同一个游戏实体或机制的同一事实时产生。技能不自行裁决而是依据注册表source:字段指向的 GDD 是权威所有者与之矛盾的其它 GDD 才是需要被更新的那一份若冲突代表一次有意的设计变更则按“先改 source GDD、再改注册表、最后修其余 GDD”的顺序处理。报告同时会对每条冲突给出 Resolution needed 建议改哪份文档、改成什么。依赖缺口。某份 GDD 的 Dependencies 引用了一个没有 GDD 的系统。测试规范用例 3 的行为技能发现 GDD-A 依赖的 system-B 在design/gdd/下不存在后在 findings 表中记录GDD-A vs (missing) | Dependency Gap | MEDIUM并建议运行/design-system system-B创建缺失的 GDD。需要说明一点文档间差异测试规范给出的判定词是三种——CONSISTENT / CONFLICTS FOUND / DEPENDENCY GAP而当前 SKILL.md 的正文报告模板写的是Verdict: PASS | CONFLICTS FOUNDPhase 6 结束后还有最终的COMPLETE一致性检查完成与BLOCKED尚有 N 个冲突需在架构开始前人工解决。两者不一致时建议以 CCGS Skill Testing Framework/CLAUDE.md 的说明为准该框架下的 spec 是撰写时对当前行为的快照、可能滞后于技能本体实际运行时以 SKILL.md 的输出为准。如何读报告扫描结束后输出的报告结构固定以下为 SKILL.md 中的模板方括号内容按实际结果填充属示例结构而非固定值## Consistency Check Report Date: [date] Registry entries checked: [N entities, N items, N formulas, N constants] GDDs scanned: [N] ([list names]) ### Conflicts Found (must resolve before architecture) [Entity/Item/Formula/Constant Name] Registry (source: [gdd]): [attribute] [value] Conflict in [other_gdd].md: [attribute] [different_value] → Resolution needed: [which doc to change and to what] ### Stale Registry Entries (registry behind the GDD) ⚠️ [Entry Name] Registry says: [value] (written [date]) Source GDD now says: [new value] → Update registry entry to match source GDD, then check referenced_by docs. ### Unverifiable References (no conflict, informational) ℹ️ [gdd].md mentions [entity_name] but states no comparable attributes. ### Clean Entries (no issues found) ✅ [N] registry entries verified across all GDDs with no conflicts. Verdict: PASS | CONFLICTS FOUND三条分类线 CONFLICT 是必须解决的同一名字在注册表与 GDD 间值不同⚠️ STALE REGISTRY 是注册表落后于 source GDD其它 GDD 可能本来就是对的先更新注册表再核对referenced_by文档ℹ️ UNVERIFIABLE 只是记录性引用不构成冲突。技能不会自动解决任何冲突——归属判断和修改都由你确认。发现问题后的处理与验证注册表修正需要你批准。若发现过期条目技能会问 May I updatedesign/registry/entities.yamlto fix the [N] stale entries?若发现 GDD 里出现注册表没有、且出现在多份 GDD 中的新条目它会问是否加入注册表只加跨系统事实单 GDD 内部事实不注册。修正方式是更新值、把revised:设为当天日期、并以注释# was: [old_value] before [date]保留旧值。技能永不删除注册表条目条目失效时改为status: deprecated。这与 entities.yaml 头部的 RULES 一致。Reflexion 日志条件写入。只要出现过 CONFLICT无论是否已解决且docs/consistency-failures.md已存在技能会按条目追加一段冲突记录日期、涉及文档、冲突内容、解决方式、教训。文件不存在则静默跳过技能不会主动创建它。验证修复。处理完被标记的 GDD 后重新运行/consistency-check确认结果从 CONFLICTS FOUND 变为 PASS才算闭环。按 SKILL.md 的 Next StepsPASS 之后可以跑/review-all-gdds做整体设计理论审查或若 MVP 的 GDD 已全部完成直接进/create-architectureCONFLICTS FOUND 则修完再重跑STALE REGISTRY 则按 Phase 6 更新注册表后重跑验证。限制与边界公式冲突检测依赖一致的公式记法。测试规范的 Coverage Notes 明确说明各 GDD 对同一机制的非正式描述可能检测不出来。想让扫描可靠各 GDD 的 Formulas 小节应使用统一的变量名与写法。分析阶段只读。扫描过程不写任何文件报告写入、注册表修正都以征求批准为前提。空注册表直接退出不会产出部分报告也不会给出 verdict——这不是故障是先补/design-system的信号。深度设计审查不归它管。结构性一致性数值、公式、归属是/consistency-check的职责pillar drift、主导策略这类设计理论层面的审查由/review-all-gdds承担两者互补而不是替代。完整的可执行定义在 .claude/skills/consistency-check/SKILL.md行为测试规范含五个测试用例无冲突、公式冲突、依赖缺口、空目录、无 director gate在 CCGS Skill Testing Framework/skills/analysis/consistency-check.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考