skill-improve

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation

自动化模式：解析 modes.automation（project.local.yaml → project.yaml → 默认值 collaborative）。每次调用 AskUserQuestion 和 每次文件写入都遵循 .claude/docs/automation-modes.md （collaborative 始终提问 · guided 仅重大事项提问 · autonomous 记录并继续； automation_always_ask 类别始终提示）。

改进技能

对单个技能运行改进循环： 测试 → 修复 → 重新测试 → 保留或还原。

其评分来自 /skill-test 静态检查和类别检查，这些检查会读取技能，而不会运行它：分数更高意味着技能写得更好，并不能证明其行为有所改善。要检查行为，请在修改前后用实际请求运行技能。

---

阶段 1：解析参数

从第一个参数中读取技能名称。如果缺失，输出用法并停止：

Usage: /skill-improve [skill-name]
Example: /skill-improve tech-debt

验证 .claude/skills/[name]/SKILL.md 是否存在。如果不存在，则停止并显示： "未找到技能 '[name]'。"

对 CCGS Skill Testing Framework/catalog.yaml 执行 Glob。如果该文件存在，先说明： "CCGS Skill Testing Framework/ 已在 1.2.0 中重命名为 studio-tests/，此 技能仅读取 studio-tests/。请将你编写的任何规范移至该目录；UPGRADING.md （v1.1.3 → v1.2.0，studio-tests/）说明了具体方法。"然后继续。

---

阶段 2：基准测试

运行 /skill-test static [name] 并记录基准分数：

• FAIL 数量
• WARN 数量
• 哪些具体检查未通过（检查 1–7）

向用户显示：

Static baseline:   [N] failures, [M] warnings
Failing: Check 4 (no ask-before-write), Check 5 (no handoff)

如果静态检查结果为 NOT ASSESSED（无法读取或解析技能文件），则停止并说明原因：没有可改进的分数，而且无法读取文件时得到的 0 个 FAIL 并不代表结果合格。

如果基准测试结果为 0 个 FAIL、0 个 WARN，则注明这一点并继续到阶段 2b。

阶段 2b：类别基准测试

在 studio-tests/catalog.yaml 中查找技能的 category: 字段。

如果未找到 category: 字段，显示： "类别：尚未分配 — 跳过类别检查。" 并跳至阶段 3。

如果找到类别，运行 /skill-test category [name] 并记录类别基准：

• FAIL 数量
• WARN 数量
• 哪些具体类别评分标准未通过

向用户显示：

Category baseline: [N] failures, [M] warnings  ([category] rubric)

类别检查结果为 NOT ASSESSED（无法找到或应用评分标准部分）时，需说明原因；这不代表结果为零：此时，在下方的“已通过”判定中不计入类别维度。

如果静态检查和类别检查的基准测试结果均为 0 个 FAIL、0 个 WARN，且两者都不是 NOT ASSESSED，则停止： "此技能已通过所有静态检查和类别检查。无需改进。"

---

阶段 3：诊断

阅读完整技能文件：.claude/skills/[name]/SKILL.md，以及其 references/ 文件夹中的每个文件（如果有）——最长的技能会将各阶段内容分别放在这些文件中。指出每个缺陷所在的文件。

对于每项未通过或警告的静态检查，找出确切缺陷：

• 检查 1 未通过 → 缺少哪个 frontmatter 字段
• 检查 2 未通过 → 找到的阶段数量与最低要求数量
• 检查 3 未通过 → 技能正文中完全没有判定关键词
• 检查 4 未通过 → allowed-tools 中包含 Write 或 Edit，但没有“写入前先征求同意”的措辞
• 检查 5 警告 → 末尾没有后续步骤或下一步章节
• 检查 6 警告 → 设置了 context: fork，但找到的阶段少于 5 个
• 检查 7 警告 → argument-hint 为空，或与文档中说明的模式不匹配

对于每项未通过或警告的类别检查（如果在阶段 2b 中指定了类别），找出技能文本中的确切缺陷。例如：

• 如果 G2 未通过（门控模式、导演面板宽度）：技能正文没有根据 modes.workflow 设置 PHASE-GATE 面板大小（minimal 时为 PR，standard 时为 TD + PR，full 时为全部 4 项）
• 如果 A2 未通过（创作、每个章节都没有“我可以写吗”询问）：技能只在最后询问一次，而不是在写入每个章节前询问
• 如果 T3 未通过（团队、未显示 BLOCKED）：技能没有在 Agent 受阻时暂停依赖它的工作

在提出任何更改前，向用户展示完整的综合诊断。

---

阶段 4：提出修复方案

针对每项未通过和警告提出有针对性的修复方案。使用清晰标注的修改前／修改后代码块展示拟议更改。只修改未通过的部分——不要重写已通过的章节。如果技能有 references/ 文件夹，针对某阶段步骤的修复应放在该阶段的 references/ 文件中，而不是改回 SKILL.md；接下来的问题应列出修复涉及的每个文件。

询问：“可以将此改进版本写入 .claude/skills/[name]/SKILL.md 吗？”

如果用户回答否，请在此处停止。

---

阶段 5：写入并重新测试

记录修复所改动的每个文件的当前内容——将确切文本保留在本次对话中，以便阶段 6 恢复。

将改进后的技能写入 .claude/skills/[name]/SKILL.md，以及修复涉及的每个 references/ 文件。

重新运行 /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: [before] → [after] (improved / no change / worse)

[before] 和 [after] 是阶段 6 的综合计数——失败与警告，以及两个维度的计数都包括在内——例如：Combined: 3 → 0 (improved)。

---

阶段 6：判定

计算综合失败总数：静态 FAIL 数 + 类别 FAIL 数 + 静态 WARN 数 + 类别 WARN 数。 如果重新测试结果为 NOT ASSESSED（例如修改破坏了 frontmatter，导致文件无法解析），无论计数如何，都不算改进：应选择下面的“未改善”分支。

如果综合评分有所改善（综合失败数低于基线）： 报告：“评分有所改善。已保留更改。” 按维度概述修复内容。

如果综合评分相同或更差： 报告：“综合评分未改善。” 说明改动内容及其可能未能奏效的原因。 询问：“可以将 .claude/skills/[name]/SKILL.md 恢复为本次运行前的内容吗？” ——列出阶段 5 写入的每个文件。 如果用户同意：使用 Write 将阶段 5 记录的内容写回每个文件；如果用户不同意，则保留已写入的文件内容。不要使用 git checkout——它会返回最后一次已提交的版本，并丢弃本次运行前尚未提交的编辑。

---

阶段 7：后续步骤

• 运行 /skill-test static all，查找下一个存在失败项的技能。
• 运行 /skill-improve [next-name]，继续处理另一个技能。
• 运行 /skill-test audit，查看整体覆盖进度。