名称： skill-reviewer
描述： 审查和评估智能体技能（SKILL.md 文件）的质量、正确性和有效性。适用于发布前评估技能、审核他人技能、评定技能质量、识别技能内容缺陷或改进现有技能。
元数据： {"clawdbot":{"emoji":"🔍","requires":{"anyBins":["npx"]},"os":["linux","darwin","win32"]}}
对智能体技能（SKILL.md 文件）进行质量、正确性和完整性的审计。提供一个结构化的审查框架，包含评分标准、缺陷检查清单和改进建议。
验证技能是否具备必需的结构。阅读文件并逐项检查：
结构检查清单：
[ ] 有效的 YAML 前言（以 --- 开头和结尾）
[ ] 存在 `name` 字段，且为有效的 slug（小写，连字符分隔）
[ ] 存在 `description` 字段，且非空
[ ] 存在 `metadata` 字段，包含有效的 JSON
[ ] `metadata.clawdbot.emoji` 是单个表情符号
[ ] `metadata.clawdbot.requires.anyBins` 列出了真实的 CLI 工具
[ ] 前言后紧跟标题（# 标题）
[ ] 标题后有摘要段落
[ ] 存在“使用场景”部分
[ ] 至少包含 3 个主要内容部分
[ ] 末尾存在“技巧”部分
描述字段影响最大。根据以下标准进行评估：
描述评分：
[2] 以技能功能开头（使用主动动词）
好："为任何项目类型编写 Makefile。"
差："本技能涵盖 Makefile。"
差："关于 Make 的全面指南。"
[2] 包含触发短语（“在……时使用”）
好："在设置构建自动化、定义多目标构建时使用"
差：完全没有触发短语
[2] 范围具体（提及具体工具、语言或操作）
好："SQLite/PostgreSQL/MySQL — 模式设计、查询、CTE、窗口函数"
差："数据库相关"
[1] 长度合理（50-200 个字符）
过短："制作东西"（缺乏搜索覆盖面）
过长：300+ 个字符（会被截断）
[1] 自然包含可搜索关键词
好："cron 作业、systemd 定时器、调度"
差：关键词生硬堆砌
得分：__/8
元数据评分：
[1] 表情符号与技能主题相关
[1] requires.anyBins 列出了技能实际使用的工具（而非通用工具如 "bash"）
[1] os 数组准确（如果命令仅限 Linux，则不要声明 win32）
[1] JSON 有效（使用 JSON 解析器测试）
得分：__/4
统计代码块和总行数：
示例密度：
总行数： ___
代码块数： ___
比例： 每 ___ 行有 1 个代码块
目标：每 8-15 行有 1 个代码块
< 8 行/块：可能过于零散
> 20 行/块：需要更多示例
对每个代码块进行检查：
示例质量检查清单：
[ ] 指定了语言标签（```bash, ```python 等）
[ ] 命令语法正确
[ ] 在有用处展示了输出（以注释形式）
[ ] 使用实际值（而非 foo/bar/baz）
[ ] 没有遗留占位符值（TODO, FIXME, xxx）
[ ] 自包含（不依赖未定义的变量）
或者展示了/引用了设置步骤
[ ] 涵盖常见情况（不只是边缘情况）
为每个示例评分 0-3：
- 0：损坏或具有误导性
- 1：可用但极简（无输出、无上下文）
- 2：良好（正确，有输出或解释）
- 3：优秀（可直接复制粘贴、实际可行、涵盖边缘情况）
组织评分：
[2] 按任务/场景组织（而非抽象概念）
好："## 编码与解码" → "## 检查字符" → "## 转换格式"
差："## 理论" → "## 类型" → "## 高级"
[2] 最常见操作放在最前面
好：基本用法 → 变体 → 高级 → 边缘情况
差：配置 → 理论 → 最后才是基本用法
[1] 章节自包含（可独立使用）
[1] 层级深度一致（不随意混用 h2 和 h4）
得分：__/6
平台检查清单：
[ ] 在相关处注明 macOS 差异
（sed -i '' 与 sed -i，brew 与 apt，BSD 与 GNU 标志）
[ ] 注明 Linux 发行版差异（apt 与 yum 与 pacman）
[ ] 如果 os 包含 "win32"，则说明 Windows 兼容性
[ ] 说明工具版本假设（Docker v2 语法、Python 3.x）
核心问题：智能体能否遵循这些指令产生正确结果？
可操作性评分：
[3] 指令是命令式的（“运行 X”、“创建 Y”）
而非：“您可能考虑……”或“建议……”
[3] 步骤逻辑顺序合理（先决条件在操作之前）
[2] 处理了错误情况（当某些操作失败时该怎么做）
[2] 描述了输出/结果（如何验证操作成功）
得分：__/10
技巧评分：
[2] 包含 5-10 个技巧
[2] 技巧非显而易见（不是“阅读文档”）
好："Makefile 的头号错误：用空格代替制表符"
差："确保测试你的代码"
[2] 技巧具体且可操作
好："使用 flock 防止 cron 作业重叠运行"
差："注意并发执行"
[1] 没有与主要内容矛盾的技巧
[1] 技巧涵盖该主题特有的陷阱/隐患
得分：__/8
技能审查记分卡
═══════════════════════════════════════
技能：[技能名称]
审查者：[智能体/人类]
日期：[日期]
类别 得分 满分
─────────────────────────────────────
结构 __ 11
描述 __ 8
元数据 __ 4
示例密度 __ 3*
示例质量 __ 3*
组织 __ 6
可操作性 __ 10
技巧 __ 8
─────────────────────────────────────
总计 __ 53+
* 示例密度和质量是按样本评分的，
不是求和。使用所有示例的平均值。
评级：
45+ 优秀 — 可发布
35-44 良好 — 需要少量改进
25-34 一般 — 需要解决显著缺陷
< 25 差 — 需要重大重写
结论：[发布 / 修订 / 重写]
缺陷：前言无效
检测：YAML 解析错误，缺少必需字段
修复：验证 YAML，确保 name/description/metadata 都存在
缺陷：代码示例损坏
检测：语法错误，未定义变量，错误标志
修复：在干净环境中测试每条命令
缺陷：工具要求错误
检测：metadata.requires 列出了内容中未使用的工具，或遗漏了实际使用的工具
修复：在内容中 grep 命令名称，更新 requires 以匹配
缺陷：描述具有误导性
检测：描述承诺了内容未涵盖的范围
修复：使描述与实际内容一致，或补充缺失内容
缺陷：缺少“使用场景”部分
影响：智能体不知道何时激活该技能
修复：添加 4-8 个描述触发场景的要点
缺陷：纯文本墙，无示例
检测：任何超过 10 行且没有代码块的部分
修复：为每个描述的概念添加具体示例
缺陷：示例缺少语言标签
检测：``` 后没有语言标识符
修复：为每个代码围栏添加 bash、python、javascript、yaml 等标签
缺陷：没有“技巧”部分
影响：缺少使技能有价值的精华经验
修复：添加 5-10 个非显而易见、可操作的技巧
缺陷：组织方式抽象
检测：章节命名为“理论”、“概述”、“背景”、“介绍”
修复：按任务/操作重新组织：用户想要“做什么”
缺陷：占位符值
检测：foo、bar、baz、example.com、1.2.3.4、TODO、FIXME
修复：替换为实际值（myapp、api.example.com、192.168.1.100）
缺陷：格式不一致
检测：混合标题层级，代码块风格不一致
修复：标准化标题层级和格式
缺陷：缺少交叉引用
检测：提及了其他技能涵盖的工具/概念，但没有引用它们
修复：添加“关于 Y 的更多信息，请参阅 X 技能”的注释
缺陷：命令过时
检测：docker-compose (v1)、python (而非 python3)、npm -g 而没有 npx 替代方案
修复：更新到当前工具版本和语法
比较同一类别的技能时：
比较标准：
1. 覆盖广度
哪个技能涵盖更多用例？
2. 示例质量
哪个有更多可运行、实际的示例？
3. 常见操作深度
哪个更好地处理了 80% 的情况？
4. 边缘情况覆盖
哪个解决了更多陷阱和失败模式？
5. 跨平台支持
哪个在更多环境中可用？
6. 时效性
哪个使用了当前工具版本和语法？
优胜者：[技能 A / 技能 B / 平局]
理由：[1-2 句话说明]
当不需要完整评分时，用于快速审查：
## 快速审查：[技能名称]
**结构**：[正常 / 问题：...]
**描述**：[强 / 弱：原因]
**示例**：[X 个代码块，共 Y 行 — 密度 正常/低/高]
**可操作性**：[智能体 能/不能 遵循这些指令，因为...]
**首要缺陷**：[最需要修复的一个问题]
**结论**：[发布 / 修订 / 重写]
# 1. 验证前言
head -20 skills/my-skill/SKILL.md
# 目视确认 YAML 有效
# 2. 统计代码块数量
grep -c '```' skills/my-skill/SKILL.md
# 用总行数除以这个数得到密度
# 3. 检查占位符
grep -n -i 'todo\|fixme\|xxx\|foo\|bar\|baz' skills/my-skill/SKILL.md
# 4. 检查缺失的语言标签
grep -n '^```$' skills/my-skill/SKILL.md
# 每个代码围栏都应有语言标签 — 单独的 ``` 是缺陷
# 5. 验证工具要求与内容匹配
# 从前言中提取 requires，然后在内容中 grep 每个工具
# 6. 测试命令（从技能中抽样 3-5 条）
# 在干净的 shell 中运行以验证其可用性
# 7. 在脑海中或文件中运行记分卡
# 目标：35+ 为良好，45+ 为优秀
# 安装技能
npx molthub@latest install skill-name
# 阅读它
cat skills/skill-name/SKILL.md
# 运行快速审查模板
# 如果得分 < 25，考虑卸载并寻找替代方案
requires.anyBins 是否与技能实际使用的内容一致。常见缺陷是列出 bash（所有环境都有）而不是实际工具如 docker、curl 或 jq。