Claude Skill 质检工具 Skill Craft
Skill Craft 是一个面向 Claude Skill 的质量工程工具，覆盖 Skill 的完整生命周期：创建、评估、修复、系统治理。
GitHub：https://github.com/3stoneBrother/skill-craft
核心问题：Skill 写出来 ≠ 用得稳
LLM 不是传统程序，写在 Skill 中的规则不会天然成为强约束，模型可能只当作"参考意见"。典型表现：
- Demo 阶段效果很好，真实任务就出问题
- 对话一变长，行为越来越飘
- Skill 一多，路由边界越来越模糊
根本原因是 LLM 存在一套"看似认真执行、实际开始偷懒"的模式。
7 类 Skill 失效模式
| # | 失效模式 | 表现 |
|---|---|---|
| 1 | 约束衰减 | 对话一长，Skill 里的规则越来越"像没写"。前五轮还严格执行，第十轮就变味 |
| 2 | 工具选择漂移 | 指定优先用某个工具，第一次超时后自动换成更熟悉的替代方案，不再回来 |
| 3 | 输出膨胀 | 要一段简明结论，回一篇论文。快速消耗上下文，加速约束失效 |
| 4 | 依赖链断裂 | Step 1 找到 29 个对象，Step 3 只处理了 20 个，中间 9 个蒸发 |
| 5 | 并行孤岛 | 两个子 Agent 产出互相矛盾的结论，主 Agent 不做校验直接合并交付 |
| 6 | 触发模糊 | 用户只是问"这个方案怎么样"，Skill 却误判成"请执行完整流程" |
| 7 | 幻觉填充 | 工具没查到结果，不说"没查到"，而是基于记忆"补一个像样的答案" |
连锁反应
这 7 类问题会连锁触发：
输出膨胀 → 上下文挤满 → 约束衰减 → 工具漂移 + 步骤跳过 + 幻觉填充
因此不是"修某一个 bug"，而是需要一套系统防错的质量框架。
Skill Craft 四大模式
| 模式 | 作用 |
|---|---|
check |
评估单个 Skill 的质量 |
fix |
基于审计结果修复 Skill，并验证修复是否有效 |
create |
从零生成一个结构完整、可验证的新 Skill |
audit |
从系统层面审计多个 Skill 的路由和一致性 |
三层评估体系
第一层：8 个结构模块
对应 Skill 在真实执行中最关键的防线：
| # | 模块 | 关键要求 |
|---|---|---|
| 1 | 触发条件 | 必须有"触发""不触发""歧义处理"三种情况 |
| 2 | 行为准则 | 明确的行为约束规则 |
| 3 | 工具优先级 | 指定工具选择优先级，防止漂移 |
| 4 | 输出约束 | 控制输出格式和长度 |
| 5 | 流程 Checkpoint | 每步有中间输出，不是写"逐个处理"而是写 已完成数 == 应完成数 |
| 6 | 依赖链 | 上下游数据传递的完整性保证 |
| 7 | 子 Agent 委派规则 | 并行结果的去重和一致性校验 |
| 8 | 幻觉防护 | 不是写"注意准确"，而是要求"没有来源就不能输出" |
第二层：7 类反模式风险覆盖
检查结构模块是否真正能防住对应的失效模式——不是"有没有模块"，而是"模块有没有防御力"。
第三层：3 条完整性原则
很多 Skill 失败是因为约束太"像人话"，不像机器可验收的规范：
- 可计数验收 — 不写"逐个处理"，要写"处理数必须等于总数"
- Checkpoint 阻断 — 每步必须有中间输出，防止模型一口气跳到最后
- 失败路径定义 — 不能只有正常路径。没写 else，模型默认的 else 往往就是 skip
fix 模式详解
发现问题不难，难的是修完后证明真的修好了。
修复流程
评估 → 输出问题清单 → 按优先级修复 → 回归验证
回归验证是关键：修完后重新评估，检查分数是否提升、风险是否下降、结构是否闭环。如果修完分数没变或新旧口径打架，不算修好。
四类关联检查
每次修复要做四类检查，防止"只改了一处，还有三处应该一起改"：
- 引用方同步 — 引用本 Skill 的文档是否需要更新
- 对称方同步 — 对称依赖的 Skill 是否需要同步调整
- 消费方同步 — 消费本 Skill 输出的下游是否受影响
- 同层相似检查 — 同类 Skill 是否存在类似问题
create 模式
目标不是生成模板，而是生成一个从第一天就尽量合规的 Skill：
- 判断 Skill 复杂度（轻量 / 中等 / 重型），决定包含哪些模块
- 生成文件
- 跑自检 + 基础校验
自动化脚本：
- validate-metadata.py — 元数据校验
- validate-structure.py — 结构校验
这两个脚本定义为 smoke check（冒烟检查），只能快速筛掉明显错误，真正的质量判断仍需回到结构、约束和流程本身。
audit 模式
解决"单个没问题，系统还是出问题"——当 Skill 数量到 5、10、20 个时，问题从单点缺陷变成系统混乱：
- 两个 Skill 的触发边界重叠
- 主文档改了，README 还在传播旧规则
- 引用链断裂但无人发现
- 一个 Skill 在修，另一个路由说明停留在旧版本
audit 关注的是整个 Skill 系统的：
- 路由边界 — 触发条件是否重叠或遗漏
- 职责分工 — Skill 间职责是否清晰
- 真值源统一 — 规则是否有唯一权威来源
- 外围文档传播 — README/引用是否同步
实际效果
在一个包含 5 个 Skill 的 Obsidian 插件系统中测试：
- 有 Skill 主文件接近 500 行，明显超预算
- 有 Skill 内容很多，但核心模块几乎没建起来
- 最致命的问题不是缺功能，而是没写清楚"DO NOT trigger"
- 系统层面多个 Skill 的触发边界存在重叠风险
安装与使用
将 Skill Craft 放入 Claude Code 的 Skills 目录：
# 放入 skills 目录
cp -r skill-craft ~/.claude/skills/
使用方式（自然语言触发）：
评估 /path/to/my-skill
GitHub 地址：https://github.com/3stoneBrother/skill-craft