Skill Reviewer

说明：这是一个Skill审核工具，用于审核其他技能的质量。文档中包含的"错误示例"（如无效 YAML、错误命名等）仅用于教学演示，展示不应该怎么写。不存在任何恶意或混淆代码。

依据 Anthropic 官方 Skills 开发指南，对技能进行全面审核。提供结构化审核框架、评分系统、缺陷检查清单和改进建议。

核心职责

1. 结构验证 - 检查文件夹结构、文件命名规范

   示例：ls skills/my-skill/ 检查 SKILL.md 是否存在

2. YAML 审核 - 验证前置信息格式和必填字段

   示例：head -20 SKILL.md 检查 name/description

3. 描述评估 - 检查触发条件是否清晰

   示例：description 应包含"当用户...时"触发条件

4. 组织评分 - 评估技能是否按任务组织、常见操作优先

   示例："## 编码和解码" ✅ vs "## 理论" ❌

5. 指令审查 - 评估主体指令的质量和完整性

   示例：是否有工作流程、示例、错误处理

6. 示例质量 - 评估示例密度和可执行性

   示例：每 5-30 行 1 个代码块为最佳密度

7. Tips 评分 - 评估技巧部分的质量和价值

   示例：5-10 条非显而易见的实用技巧

8. 最佳实践 - 对照官方指南检查合规性

   示例：检查是否按任务组织而非抽象概念

工作流程

第 1 步：接收审核请求

当用户请求审核 skill 时：

1. 确认 skill 文件夹路径或读取 SKILL.md 内容
2. 判断审核严格程度：

严格模式（必须读取完整版官方指南）： 当用户表达以下意图时，必须先读取 references/anthropic-skills-development-guide.md 完整版指南：

• 明确要求"严格检查"、"仔细审核"、"全面审查"
• 提到"高质量要求"、"生产级别"、"发布前检查"
• 表达"不想有任何遗漏"、"按最高标准"
• 用于团队/组织/公司项目
• 准备公开发布或分享给他人

常规模式：

• 优先读取 references/checklist.md（快速检查清单）
• 遇到疑问或边缘案例时读取完整版官方指南

第 2 步：结构检查

文件夹结构验证：

[ ] 技能文件夹使用 kebab-case 命名（如 my-skill）
[ ] SKILL.md 存在且命名精确（区分大小写）
[ ] 无 README.md 在技能文件夹内
[ ] 可选文件夹（如存在）命名规范

可选文件夹命名规范（如存在）：

• scripts/ - 全小写复数，无空格/下划线
• references/ - 全小写复数，无空格/下划线
• assets/ - 全小写复数，无空格/下划线

❌ 错误示例： Scripts、script、scripts_backup、References、refs、Assets、asset_files

示例：检查文件夹结构

# 查看技能文件夹结构
ls -la skills/china-holidays/

预期输出：

skills/china-holidays/
├── SKILL.md          # ✅ 正确：精确命名
└── references/       # ✅ 正确：全小写复数
    └── calendar-guide.md

评分：__/4

第 3 步：YAML 前置信息检查

必填字段验证：

[ ] name 字段存在，kebab-case，无空格大写
[ ] description 字段存在，非空
[ ] YAML 分隔符完整（--- 开头和结尾）
[ ] 无 XML 标签（< >）
[ ] name 不以 claude/anthropic 开头

示例：验证 YAML 前置信息

# 读取前 20 行检查 YAML
head -20 skills/china-holidays/SKILL.md

预期输出（正确示例）：

---
name: china-holidays
description: 获取中国国家法定节假日安排。当用户询问"放假安排"、"节假日"时使用。
---

错误示例（应该拒绝）：

name: ChinaHolidays        # ❌ 大写，应该 kebab-case
name: claude-scheduler     # ❌ 以 claude 开头
description: ""            # ❌ 空描述
<skill>                    # ❌ 包含 XML 标签

Description 质量评分（满分 8 分）：

[2] 开头说明做什么（主动动词）
    好："分析 Figma 设计文件并生成开发者交接文档"
    差："这是关于 Figma 的技能"

[2] 包含触发条件（"当用户...时"）
    好："当用户上传 .fig 文件或询问设计规格时使用"
    差：无触发条件

[2] 具体范围（提及具体工具、操作或场景）
    好："Figma 设计文件、.fig、组件文档、设计交接"
    差："帮助处理项目"

[2] 合理长度（50-200 字符，不超过 1024）
    太短：无搜索价值
    太长：被截断

评分：__/8

第 4 步：组织评分

按任务/场景组织（而非按抽象概念）：

[2] 按任务/操作组织章节
    好："## 编码和解码" → "## 检查字符" → "## 转换格式"
    差："## 理论" → "## 类型" → "## 高级"

[2] 常见操作优先
    好：基础用法 → 变体 → 高级 → 边界情况
    差：配置说明 → 理论背景 → 最后才是基础用法

[1] 章节自包含（可独立使用）

[1] 深度一致（不混用 h2 与 h4 随机跳转）

评分：__/6

第 5 步：主体指令检查

必须包含：

[ ] 清晰的工作流程或步骤说明
[ ] 至少一个使用示例
[ ] 错误处理或故障排查指南