Claude Code Game Studios 技能自愈机制用 skill-improve 的 test-fix-retest 闭环维护 SKILL.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本篇技术指南聚焦 Claude Code Game StudiosCCGS框架中的元技能meta-utility skillskill-improve它基于「测试 → 修复 → 重测 → 保留或回滚」的循环自动定位并修复单个技能文件中不合规的部分。在 CCGS 中72 个工作流技能的质量由 skill-test 以结构化检查与类别化评分统一度量而skill-improve正是让这一度量体系具备「自愈」能力的闭环引擎。读完本文你将掌握 skill-improve 的七阶段执行流程、它与 skill-test 三种模式static / category / audit的协作方式、基于分数对比的回归判定与 git 回滚策略以及如何借助 validate-skill-change.sh 钩子让技能修改的合规性检查常态化。一、为什么需要一个会自我改进的技能CCGS 将 Claude Code 组织成一个完整的游戏开发工作室49 个 AI Agent、72 个 workflow skills外加一套镜像真实工作室层级结构的协调系统。技能skill是这套体系的「方法论载体」——每个.claude/skills/[name]/SKILL.md文件都定义了某个工作流如技术债扫描、门禁检查、GDD 评审应如何分阶段执行。但方法论文件同样会腐化frontmatter 字段缺失、阶段划分不足、缺少协作协议语言、收尾没有交接建议……这些问题不会立刻让技能崩溃却会随着技能的反复调用被放大最终破坏整个框架的一致性。于是 CCGS 在 CCGS Skill Testing Framework 中内置了两套元技能skill-test负责「度量」提供 static结构 lint、spec行为验证、category类别评分、audit覆盖率报告四种模式skill-improve本文主角负责「修复」只对单个技能执行一轮 test-fix-retest 闭环根据分数变化决定保留修改还是回滚。两者的分工在框架入口 CCGS Skill Testing Framework/README.md 中有明确说明/skill-test static [skill-name]检查单个技能的 7 项结构合规而/skill-improve gate-check则运行「测试 → 诊断 → 提议修复 → 重测」的完整闭环。二、skill-improve 的定位与执行前提skill-improve 的 SKILL.md 顶部 frontmatter 定义了其基本契约name: skill-improve description: Improve a skill using a test-fix-retest loop. Runs static checks, proposes targeted fixes, rewrites the skill, re-tests, and keeps or reverts based on score change. argument-hint: [skill-name] user-invocable: true allowed-tools: Read, Glob, Grep, Write, Bash几个关键点argument-hint: [skill-name]表明它一次只处理一个技能不接受all之类的批量参数allowed-tools中包含Write与Bash这是它区别于大多数「只读分析型」技能的根本原因——它被授权改写技能文件并在需要时执行git checkout回滚它属于utility类别在 catalog.yaml 中登记为category: utility、priority: low。根据 quality-rubric.mdutility 类技能只需满足 U1通过全部 7 项静态检查与 U2若触发导演门禁则门禁模式正确。从源码结构可以推断skill-improve 的设计哲学是「可逆优先」。它在动手前记录原文件内容测试不通过时主动提议回滚且回滚同样需要用户确认绝不自动覆盖。三、七阶段闭环从参数解析到交接建议skill-improve 的执行体由 7 个 Phase 组成严格按顺序推进。下面逐阶段还原其完整逻辑。Phase 1解析参数Parse Argument从第一个参数读取技能名缺失时输出用法并停止Usage: /skill-improve [skill-name] Example: /skill-improve tech-debt随后校验.claude/skills/[name]/SKILL.md是否存在不存在则停止并提示Skill [name] not found.。Phase 2基线测试Baseline Test运行/skill-test static [name]并记录基线分数包含三要素FAIL 数量WARN 数量具体失败项Check 1–7向用户展示Static baseline: [N] failures, [M] warnings Failing: Check 4 (no ask-before-write), Check 5 (no handoff)若基线为 0 FAIL 且 0 WARN记录后进入 Phase 2b 做类别基线。Phase 2b类别基线Category Baseline在 catalog.yaml 中查找该技能的category:字段无category:字段 → 显示Category: not yet assigned — skipping category checks.并直接跳至 Phase 3有category:字段 → 运行/skill-test category [name]记录类别基线的 FAIL 数、WARN 数与具体失败指标显示Category baseline: [N] failures, [M] warnings ([category] rubric)早退条件若 static 与 category 两项基线均为 0 FAIL、0 WARN则停止并提示This skill already passes all static and category checks. No improvements needed.这与测试规范 CCGS Skill Testing Framework/skills/utility/skill-improve.md 中的 Case 4 完全吻合brainstorm已满分时技能立即退出不提议任何改动、不询问 May-I-write、verdict 为 NO CHANGE。Phase 3诊断Diagnose完整读取.claude/skills/[name]/SKILL.md针对每一项失败或告警的 static 检查定位精确缺口检查失败/告警含义诊断口径Check 1FAIL具体缺失哪个 frontmatter 字段Check 2FAIL找到的阶段数 vs 最低要求≥2 个## Phase N或## N.标题Check 3FAIL全文不存在任何 verdict 关键词Check 4FAILallowed-tools 含 Write/Edit 却无 ask-before-write 语言Check 5WARN结尾缺少后续步骤/交接小节Check 6WARNcontext: fork已设置但阶段数不足 5 个Check 7WARNargument-hint 为空或与正文文档化模式不一致对于已分配类别Phase 2b的技能还需按类别评分表定位文本缺口例如 quality-rubric.md 中 gate 类技能G2 失败意味着正文从未引用 4 个 PHASE-GATE 导演提示词authoring 类 A2 失败意味着只在结尾询问一次而非每小节写入前询问team 类 T3 失败意味着被阻塞的 Agent 未阻断依赖工作。诊断完成后先向用户完整展示合并诊断结果再提出任何修改建议。Phase 4提议修复Propose Fix为每个失败/告警编写针对性修复用清晰的 before/after 块展示改动。关键原则只改失败项不重写已通过的小节询问May I write this improved version to .claude/skills/[name]/SKILL.md?用户拒绝则在此停止。这条「May I write」协作协议是 CCGS 的硬性要求skill-test 的 Check 4 规定只要 allowed-tools 含 Write/Edit 且正文没有 ask-before-write 语言即判 FAIL可见该协议同时约束着被测试的技能与执行改进的元技能自身。Phase 5写入并重测Write and Retest先记录当前文件内容供回滚使用再写入改进后的技能文件。随后重跑/skill-test static [name]若已分配类别同时重跑/skill-test category [name]。输出对比Static: Before [N] failures, [M] warnings → After [N] failures, [M] warnings Category: Before [N] failures, [M] warnings → After [N] failures, [M] warnings (if applicable) Combined change: improved / no change / worsePhase 6判定Verdict合并失败总数 static FAILs category FAILs static WARNs category WARNs。分数下降合并失败数低于基线报告Score improved. Changes kept.并逐维度总结修复内容分数持平或恶化报告Combined score did not improve.说明改动内容及可能无效的原因然后询问May I revert .claude/skills/[name]/SKILL.md using git checkout?确认后执行git checkout -- .claude/skills/[name]/SKILL.md这一阶段正是测试规范 skill-improve.md 中 Case 2 的验证对象修复丢失了 verdict 关键词段落导致分数从 6/7 跌到 5/7系统检测到回归后必须征询用户而非自动回滚。Phase 7下一步Next Steps闭环收尾提供三个后续入口/skill-test static all— 找出下一个存在失败的技能/skill-improve [next-name]— 对另一个技能继续循环/skill-test audit— 查看整体覆盖率进展。四、与 skill-test 的度量体系深度协作skill-improve 本身不做度量它的全部决策都建立在 skill-test 的输出之上。理解 skill-test 的检查语义是正确使用 skill-improve 的前提。以 skill-test/SKILL.md 中的 static 模式为例7 项结构检查的判定规则如下Check名称判定1Required Frontmatter Fields缺少name/description/argument-hint/user-invocable/allowed-tools任一 → FAIL2Multiple Phases少于 2 个## Phase N、## N.或##标题 → FAIL3Verdict Keywords无 PASS/FAIL/CONCERNS/APPROVED/BLOCKED/COMPLETE/READY/COMPLIANT/NON-COMPLIANT 任一 → FAIL4Collaborative Protocol Language无 ask-before-write 语言 → WARNallowed-tools 含 Write/Edit 仍无 → FAIL5Next-Step Handoff结尾无推荐下一步/Follow-Up → WARN6Fork Context Complexitycontext: fork但阶段 5 → WARN7Argument Hint Plausibilityhint 为空或与正文模式不符 → WARN值得注意 Check 4 的 WARN/FAIL 分级只读型技能可以合理省略 ask-before-write 语言判 WARN但只要声明了 Write/Edit 权限就必须有协作协议判 FAIL。这与 quality-rubric.md 中 review 类技能的例外条款一脉相承——design-review拥有 Write/Edit 权限却仍满足 R1正是因为其所有写入都挂在用户批准之后。此外类别评分表 quality-rubric.md 为每个类别定义了 4–5 条二元 PASS/FAIL 指标gate 类看 G1–G5如 G5「无自动推进」要求写入production/stage.txt必须经 May-I-write、team 类看 T1–T5如 T3「BLOCKED 必须浮出」、utility 类只看 U1–U2。skill-improve 在 Phase 2b/3/5 对这些指标做同样的「基线—诊断—重测」处理合并分数参与 Phase 6 的判定。五、回归安全为什么回滚也需要用户确认skill-improve 的回归处理有三个值得借鉴的设计点写前留痕Phase 5 在写入前记录当前文件内容保证回滚有据可依对比驱动判定判定依据是「合并失败总数」而非主观感受杜绝了「感觉改好了」的误判回滚双确认git checkout需要用户明确同意——因为技能文件可能已被用户额外修改自动回滚有覆盖风险。从测试规范 skill-improve.md 的 Coverage Notes 还可以看到明确的边界声明每次调用只执行一轮 fix-retest 循环多轮迭代需要重新调用/skill-improve行为合规spec 模式结果不纳入改进循环只有结构static与类别category分数参与自动化判定。六、让改进闭环常态化的钩子机制skill-improve 解决的是「主动修复」而 CCGS 还用 PostToolUse 钩子解决「及时提醒」。查看 validate-skill-change.sh该脚本在Write/Edit工具写入.claude/skills/下任何文件时触发通过jq无 jq 时回退 grep解析工具输入中的file_path路径规范化后仅对匹配(^|/)\.claude/skills/的文件生效从.claude/skills/[skill-name]/SKILL.md提取技能名向 stderr 输出提示 Skill Modified: $SKILL_NAME Run /skill-test static $SKILL_NAME to validate structural compliance. 该钩子以exit 0结束仅提示、不阻断与 skill-improve 形成互补钩子把「改完技能就去测」变成肌肉记忆skill-improve 把「测出问题就去修」变成自动化流程。七、实操演练对一个典型技能执行改进闭环以tech-debt技能frontmatter 见 .claude/skills/tech-debt/SKILL.md为例模拟完整调用路径/skill-improve tech-debtPhase 1解析技能名tech-debt确认.claude/skills/tech-debt/SKILL.md存在Phase 2运行/skill-test static tech-debt假设基线为1 failure, 1 warning失败项为 Check 4无 ask-before-write与 Check 5无 handoffPhase 2b在 catalog.yaml 中查到tech-debt的category: analysis运行/skill-test category tech-debt得到 AN 系指标的类别基线Phase 3对照正文定位缺口——Check 4 缺口是扫描模式允许 Write 却无批准语言AN3 缺口同理Phase 4提议在写入 debt register 前加入May I write this entry to the debt register?并在文末补充「Recommended next: /skill-test spec tech-debt」小节Phase 5记录原文件、写入、重测 static 与 categoryPhase 6合并失败数下降则保留Score improved. Changes kept.持平或恶化则征询git checkout回滚Phase 7可继续/skill-test static all寻找下一个失败技能。需要注意的是tech-debt的实际 frontmattertech-debt/SKILL.md已包含完整的五字段并声明allowed-tools: Read, Glob, Grep, Write说明它自带写权限——这正是 Check 4 最典型的适用场景有写权限就必须有协作协议。八、设计要点速查一次只改进一个技能/skill-improve [skill-name]不接受批量参数批量发现问题用/skill-test static all。先基线后改动任何修改前必须先跑 static有 category 时加跑 category早退条件为双零失败。只修失败项不要顺手重构已通过的段落控制改动面才能保证判定可信。May-I-write 双向约束改进者与被改进者都必须遵守协作协议被改进技能若声明 Write/Edit 却无协议语言本身就是 Check 4 的 FAIL。回归判定看合并分static FAILs category FAILs static WARNs category WARNs分数不升即回滚候选。回滚走 git checkoutgit checkout -- .claude/skills/[name]/SKILL.md且必须经用户确认。闭环接力/skill-test audit查看覆盖率 →/skill-test static all定位失败 →/skill-improve [name]修复 → 钩子在修改发生时自动提醒验证。skill-improve 把「测试驱动」的工程纪律延伸到了 AI 工作流自身的维护上技能文件不再是写一次就凝固的静态文档而是可以被度量、被诊断、被修复、被回滚的活资产。对于维护 72 个技能的 CCGS 而言这套自愈闭环正是其长期一致性的底层保障。【免费下载链接】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），仅供参考 
长河君 · 2026/9/12 18:45:31 · 阅读 1.2k Claude Code Game Studios 技能自愈机制：用 skill-improve 的 test-fix-retest 闭环维护 SKILL.md 质量
Claude Code Game Studios 技能自愈机制用 skill-improve 的 test-fix-retest 闭环维护 SKILL.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本篇技术指南聚焦 Claude Code Game StudiosCCGS框架中的元技能meta-utility skillskill-improve它基于「测试 → 修复 → 重测 → 保留或回滚」的循环自动定位并修复单个技能文件中不合规的部分。在 CCGS 中72 个工作流技能的质量由 skill-test 以结构化检查与类别化评分统一度量而skill-improve正是让这一度量体系具备「自愈」能力的闭环引擎。读完本文你将掌握 skill-improve 的七阶段执行流程、它与 skill-test 三种模式static / category / audit的协作方式、基于分数对比的回归判定与 git 回滚策略以及如何借助 validate-skill-change.sh 钩子让技能修改的合规性检查常态化。一、为什么需要一个会自我改进的技能CCGS 将 Claude Code 组织成一个完整的游戏开发工作室49 个 AI Agent、72 个 workflow skills外加一套镜像真实工作室层级结构的协调系统。技能skill是这套体系的「方法论载体」——每个.claude/skills/[name]/SKILL.md文件都定义了某个工作流如技术债扫描、门禁检查、GDD 评审应如何分阶段执行。但方法论文件同样会腐化frontmatter 字段缺失、阶段划分不足、缺少协作协议语言、收尾没有交接建议……这些问题不会立刻让技能崩溃却会随着技能的反复调用被放大最终破坏整个框架的一致性。于是 CCGS 在 CCGS Skill Testing Framework 中内置了两套元技能skill-test负责「度量」提供 static结构 lint、spec行为验证、category类别评分、audit覆盖率报告四种模式skill-improve本文主角负责「修复」只对单个技能执行一轮 test-fix-retest 闭环根据分数变化决定保留修改还是回滚。两者的分工在框架入口 CCGS Skill Testing Framework/README.md 中有明确说明/skill-test static [skill-name]检查单个技能的 7 项结构合规而/skill-improve gate-check则运行「测试 → 诊断 → 提议修复 → 重测」的完整闭环。二、skill-improve 的定位与执行前提skill-improve 的 SKILL.md 顶部 frontmatter 定义了其基本契约name: skill-improve description: Improve a skill using a test-fix-retest loop. Runs static checks, proposes targeted fixes, rewrites the skill, re-tests, and keeps or reverts based on score change. argument-hint: [skill-name] user-invocable: true allowed-tools: Read, Glob, Grep, Write, Bash几个关键点argument-hint: [skill-name]表明它一次只处理一个技能不接受all之类的批量参数allowed-tools中包含Write与Bash这是它区别于大多数「只读分析型」技能的根本原因——它被授权改写技能文件并在需要时执行git checkout回滚它属于utility类别在 catalog.yaml 中登记为category: utility、priority: low。根据 quality-rubric.mdutility 类技能只需满足 U1通过全部 7 项静态检查与 U2若触发导演门禁则门禁模式正确。从源码结构可以推断skill-improve 的设计哲学是「可逆优先」。它在动手前记录原文件内容测试不通过时主动提议回滚且回滚同样需要用户确认绝不自动覆盖。三、七阶段闭环从参数解析到交接建议skill-improve 的执行体由 7 个 Phase 组成严格按顺序推进。下面逐阶段还原其完整逻辑。Phase 1解析参数Parse Argument从第一个参数读取技能名缺失时输出用法并停止Usage: /skill-improve [skill-name] Example: /skill-improve tech-debt随后校验.claude/skills/[name]/SKILL.md是否存在不存在则停止并提示Skill [name] not found.。Phase 2基线测试Baseline Test运行/skill-test static [name]并记录基线分数包含三要素FAIL 数量WARN 数量具体失败项Check 1–7向用户展示Static baseline: [N] failures, [M] warnings Failing: Check 4 (no ask-before-write), Check 5 (no handoff)若基线为 0 FAIL 且 0 WARN记录后进入 Phase 2b 做类别基线。Phase 2b类别基线Category Baseline在 catalog.yaml 中查找该技能的category:字段无category:字段 → 显示Category: not yet assigned — skipping category checks.并直接跳至 Phase 3有category:字段 → 运行/skill-test category [name]记录类别基线的 FAIL 数、WARN 数与具体失败指标显示Category baseline: [N] failures, [M] warnings ([category] rubric)早退条件若 static 与 category 两项基线均为 0 FAIL、0 WARN则停止并提示This skill already passes all static and category checks. No improvements needed.这与测试规范 CCGS Skill Testing Framework/skills/utility/skill-improve.md 中的 Case 4 完全吻合brainstorm已满分时技能立即退出不提议任何改动、不询问 May-I-write、verdict 为 NO CHANGE。Phase 3诊断Diagnose完整读取.claude/skills/[name]/SKILL.md针对每一项失败或告警的 static 检查定位精确缺口检查失败/告警含义诊断口径Check 1FAIL具体缺失哪个 frontmatter 字段Check 2FAIL找到的阶段数 vs 最低要求≥2 个## Phase N或## N.标题Check 3FAIL全文不存在任何 verdict 关键词Check 4FAILallowed-tools 含 Write/Edit 却无 ask-before-write 语言Check 5WARN结尾缺少后续步骤/交接小节Check 6WARNcontext: fork已设置但阶段数不足 5 个Check 7WARNargument-hint 为空或与正文文档化模式不一致对于已分配类别Phase 2b的技能还需按类别评分表定位文本缺口例如 quality-rubric.md 中 gate 类技能G2 失败意味着正文从未引用 4 个 PHASE-GATE 导演提示词authoring 类 A2 失败意味着只在结尾询问一次而非每小节写入前询问team 类 T3 失败意味着被阻塞的 Agent 未阻断依赖工作。诊断完成后先向用户完整展示合并诊断结果再提出任何修改建议。Phase 4提议修复Propose Fix为每个失败/告警编写针对性修复用清晰的 before/after 块展示改动。关键原则只改失败项不重写已通过的小节询问May I write this improved version to .claude/skills/[name]/SKILL.md?用户拒绝则在此停止。这条「May I write」协作协议是 CCGS 的硬性要求skill-test 的 Check 4 规定只要 allowed-tools 含 Write/Edit 且正文没有 ask-before-write 语言即判 FAIL可见该协议同时约束着被测试的技能与执行改进的元技能自身。Phase 5写入并重测Write and Retest先记录当前文件内容供回滚使用再写入改进后的技能文件。随后重跑/skill-test static [name]若已分配类别同时重跑/skill-test category [name]。输出对比Static: Before [N] failures, [M] warnings → After [N] failures, [M] warnings Category: Before [N] failures, [M] warnings → After [N] failures, [M] warnings (if applicable) Combined change: improved / no change / worsePhase 6判定Verdict合并失败总数 static FAILs category FAILs static WARNs category WARNs。分数下降合并失败数低于基线报告Score improved. Changes kept.并逐维度总结修复内容分数持平或恶化报告Combined score did not improve.说明改动内容及可能无效的原因然后询问May I revert .claude/skills/[name]/SKILL.md using git checkout?确认后执行git checkout -- .claude/skills/[name]/SKILL.md这一阶段正是测试规范 skill-improve.md 中 Case 2 的验证对象修复丢失了 verdict 关键词段落导致分数从 6/7 跌到 5/7系统检测到回归后必须征询用户而非自动回滚。Phase 7下一步Next Steps闭环收尾提供三个后续入口/skill-test static all— 找出下一个存在失败的技能/skill-improve [next-name]— 对另一个技能继续循环/skill-test audit— 查看整体覆盖率进展。四、与 skill-test 的度量体系深度协作skill-improve 本身不做度量它的全部决策都建立在 skill-test 的输出之上。理解 skill-test 的检查语义是正确使用 skill-improve 的前提。以 skill-test/SKILL.md 中的 static 模式为例7 项结构检查的判定规则如下Check名称判定1Required Frontmatter Fields缺少name/description/argument-hint/user-invocable/allowed-tools任一 → FAIL2Multiple Phases少于 2 个## Phase N、## N.或##标题 → FAIL3Verdict Keywords无 PASS/FAIL/CONCERNS/APPROVED/BLOCKED/COMPLETE/READY/COMPLIANT/NON-COMPLIANT 任一 → FAIL4Collaborative Protocol Language无 ask-before-write 语言 → WARNallowed-tools 含 Write/Edit 仍无 → FAIL5Next-Step Handoff结尾无推荐下一步/Follow-Up → WARN6Fork Context Complexitycontext: fork但阶段 5 → WARN7Argument Hint Plausibilityhint 为空或与正文模式不符 → WARN值得注意 Check 4 的 WARN/FAIL 分级只读型技能可以合理省略 ask-before-write 语言判 WARN但只要声明了 Write/Edit 权限就必须有协作协议判 FAIL。这与 quality-rubric.md 中 review 类技能的例外条款一脉相承——design-review拥有 Write/Edit 权限却仍满足 R1正是因为其所有写入都挂在用户批准之后。此外类别评分表 quality-rubric.md 为每个类别定义了 4–5 条二元 PASS/FAIL 指标gate 类看 G1–G5如 G5「无自动推进」要求写入production/stage.txt必须经 May-I-write、team 类看 T1–T5如 T3「BLOCKED 必须浮出」、utility 类只看 U1–U2。skill-improve 在 Phase 2b/3/5 对这些指标做同样的「基线—诊断—重测」处理合并分数参与 Phase 6 的判定。五、回归安全为什么回滚也需要用户确认skill-improve 的回归处理有三个值得借鉴的设计点写前留痕Phase 5 在写入前记录当前文件内容保证回滚有据可依对比驱动判定判定依据是「合并失败总数」而非主观感受杜绝了「感觉改好了」的误判回滚双确认git checkout需要用户明确同意——因为技能文件可能已被用户额外修改自动回滚有覆盖风险。从测试规范 skill-improve.md 的 Coverage Notes 还可以看到明确的边界声明每次调用只执行一轮 fix-retest 循环多轮迭代需要重新调用/skill-improve行为合规spec 模式结果不纳入改进循环只有结构static与类别category分数参与自动化判定。六、让改进闭环常态化的钩子机制skill-improve 解决的是「主动修复」而 CCGS 还用 PostToolUse 钩子解决「及时提醒」。查看 validate-skill-change.sh该脚本在Write/Edit工具写入.claude/skills/下任何文件时触发通过jq无 jq 时回退 grep解析工具输入中的file_path路径规范化后仅对匹配(^|/)\.claude/skills/的文件生效从.claude/skills/[skill-name]/SKILL.md提取技能名向 stderr 输出提示 Skill Modified: $SKILL_NAME Run /skill-test static $SKILL_NAME to validate structural compliance. 该钩子以exit 0结束仅提示、不阻断与 skill-improve 形成互补钩子把「改完技能就去测」变成肌肉记忆skill-improve 把「测出问题就去修」变成自动化流程。七、实操演练对一个典型技能执行改进闭环以tech-debt技能frontmatter 见 .claude/skills/tech-debt/SKILL.md为例模拟完整调用路径/skill-improve tech-debtPhase 1解析技能名tech-debt确认.claude/skills/tech-debt/SKILL.md存在Phase 2运行/skill-test static tech-debt假设基线为1 failure, 1 warning失败项为 Check 4无 ask-before-write与 Check 5无 handoffPhase 2b在 catalog.yaml 中查到tech-debt的category: analysis运行/skill-test category tech-debt得到 AN 系指标的类别基线Phase 3对照正文定位缺口——Check 4 缺口是扫描模式允许 Write 却无批准语言AN3 缺口同理Phase 4提议在写入 debt register 前加入May I write this entry to the debt register?并在文末补充「Recommended next: /skill-test spec tech-debt」小节Phase 5记录原文件、写入、重测 static 与 categoryPhase 6合并失败数下降则保留Score improved. Changes kept.持平或恶化则征询git checkout回滚Phase 7可继续/skill-test static all寻找下一个失败技能。需要注意的是tech-debt的实际 frontmattertech-debt/SKILL.md已包含完整的五字段并声明allowed-tools: Read, Glob, Grep, Write说明它自带写权限——这正是 Check 4 最典型的适用场景有写权限就必须有协作协议。八、设计要点速查一次只改进一个技能/skill-improve [skill-name]不接受批量参数批量发现问题用/skill-test static all。先基线后改动任何修改前必须先跑 static有 category 时加跑 category早退条件为双零失败。只修失败项不要顺手重构已通过的段落控制改动面才能保证判定可信。May-I-write 双向约束改进者与被改进者都必须遵守协作协议被改进技能若声明 Write/Edit 却无协议语言本身就是 Check 4 的 FAIL。回归判定看合并分static FAILs category FAILs static WARNs category WARNs分数不升即回滚候选。回滚走 git checkoutgit checkout -- .claude/skills/[name]/SKILL.md且必须经用户确认。闭环接力/skill-test audit查看覆盖率 →/skill-test static all定位失败 →/skill-improve [name]修复 → 钩子在修改发生时自动提醒验证。skill-improve 把「测试驱动」的工程纪律延伸到了 AI 工作流自身的维护上技能文件不再是写一次就凝固的静态文档而是可以被度量、被诊断、被修复、被回滚的活资产。对于维护 72 个技能的 CCGS 而言这套自愈闭环正是其长期一致性的底层保障。【免费下载链接】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），仅供参考