skill-judge

Skill Judge

对照官方规范以及从 17+ 个官方示例中提炼出的模式，评估 Agent Skills。

---

核心理念

什么是 Skill？

Skill 不是教程。Skill 是一种知识外化机制。

传统 AI 知识被锁定在模型参数中。要教会它新能力：

Traditional: Collect data → GPU cluster → Train → Deploy new version
Cost: $10,000 - $1,000,000+
Timeline: Weeks to months

Skill 改变了这一点：

Skill: Edit SKILL.md → Save → Takes effect on next invocation
Cost: $0
Timeline: Instant

这是从“训练 AI”到“教育 AI”的范式转变——就像一个无需训练、可热插拔的 LoRA 适配器。你编辑一个自然语言写的 Markdown 文件，模型的行为就会改变。

核心公式

好的 Skill = 仅专家掌握的知识 − Claude 已经知道的内容

Skill 的价值由其知识增量衡量——即它提供的内容与模型已经知道的内容之间的差距。

• 仅专家掌握的知识：决策树、权衡取舍、边缘情况、反模式、领域特定的思维框架——需要多年经验才能积累的东西
• Claude 已经知道的内容：基本概念、标准库用法、常见编程模式、通用最佳实践

当 Skill 解释“什么是 PDF”或“如何写 for 循环”时，它是在压缩 Claude 已经拥有的知识。这是token 浪费——上下文窗口是一种公共资源，与系统提示词、对话历史、其他 Skills 以及用户请求共享。

工具 vs Skill

概念	本质	功能	示例
工具	模型能做什么	执行操作	bash、read_file、write_file、WebSearch
Skill	模型知道如何做什么	指导决策	PDF 处理、MCP 构建、前端设计

工具定义能力边界——没有 bash 工具，模型无法执行命令。 Skills 注入知识——没有 frontend-design Skill，模型只能产出通用 UI。

等式：

General Agent + Excellent Skill = Domain Expert Agent

同一个 Claude 模型，加载不同的 Skills，就会成为不同的专家。

Skills 中的三类知识

评估时，对每个部分进行分类：

类型	定义	处理方式
专家	Claude 确实不知道这一点	必须保留——这是 Skill 的价值
激活	Claude 知道但可能不会想到	如果简短则保留——作为提醒
冗余	Claude 肯定知道这一点	应删除——浪费 token

Skill 设计的艺术在于最大化专家内容，节制使用激活内容，并无情消除冗余内容。

---

评估维度（总分 120 分）

D1：知识增量（20 分）——核心维度

最重要的维度。该 Skill 是否增加了真正的专家知识？

分数	标准
0-5	解释 Claude 已知的基础内容（什么是 X、如何写代码、标准库教程）
6-10	混合：一些专家知识被显而易见的内容稀释
11-15	主要是专家知识，冗余极少
16-20	纯知识增量——每一段都值得其消耗的 token

危险信号（直接得分 ≤5）：

• “什么是[基本概念]”部分
• 针对标准操作的分步教程
• 解释如何使用常见库
• 通用最佳实践（“编写整洁代码”、“处理错误”）
• 行业标准术语的定义

积极信号（高知识增量的指标）：

• 针对非显而易见选择的决策树（“当 X 失败时，尝试 Y，因为 Z”）
• 只有专家才会知道的权衡取舍（“A 更快，但 B 能处理边缘情况 C”）
• 来自真实经验的边缘情况
• “永远不要做 X，因为[非显而易见的原因]”
• 领域特定的思维框架

评估问题：

1. 对每个部分，问：“Claude 已经知道这一点吗？”
2. 如果它在解释某事，问：“这是在向 Claude 解释，还是为 Claude 而解释？”
3. 统计专家、激活、冗余三类段落的数量

---

D2：思维方式 + 适当的流程（15 分）

该 Skill 是否在传递专家思维模式的同时，也传递了必要的领域特定流程？

专家与新手的区别不在于"知道如何操作"，而在于"如何思考问题"。但当 Claude 缺乏领域特定的流程性知识时，仅有思维模式是不够的。

关键区别：

类型	示例	价值
思维模式	"在设计之前，先问：是什么让这件事令人难忘？"	高 —— 塑造决策方式
领域特定流程	"OOXML 工作流：解包 → 编辑 XML → 校验 → 打包"	高 —— Claude 可能并不知道
通用流程	"第 1 步：打开文件，第 2 步：编辑，第 3 步：保存"	低 —— Claude 已经知道

分数	标准
0-3	只有 Claude 已经知道的通用流程
4-7	有领域流程，但缺乏思维框架
8-11	平衡良好：思维模式 + 领域特定工作流
12-15	专家级：既塑造思维，又提供 Claude 原本不知道的流程

什么样的流程算是有价值的：

• Claude 未曾接受过训练的工作流（新工具、专有系统）
• 不显而易见的正确顺序（例如，"打包之前先校验，而不是之后"）
• 容易遗漏的关键步骤（例如，"编辑后必须重新计算公式"）
• 领域特定的顺序（例如，MCP 服务的 4 阶段开发流程）

什么样的流程算是冗余的：

• 通用文件操作（打开、读取、写入、保存）
• 标准编程模式（循环、条件、错误处理）
• 文档完善的常见库用法

专家思维模式的样子：

Before [action], ask yourself:
- **Purpose**: What problem does this solve? Who uses it?
- **Constraints**: What are the hidden requirements?
- **Differentiation**: What makes this solution memorable?

有价值的领域流程的样子：

### Redlining Workflow (Claude wouldn't know this sequence)
1. Convert to markdown: `pandoc --track-changes=all`
2. Map text to XML: grep for text in document.xml
3. Implement changes in batches of 3-10
4. Pack and verify: check ALL changes were applied

冗余的通用流程的样子：

Step 1: Open the file
Step 2: Find the section
Step 3: Make the change
Step 4: Save and test

检验方法：

1. 它是否告诉 Claude 应该思考什么？（思维模式）
2. 它是否告诉 Claude 如何去做它原本不知道的事？（领域流程）

一个好的 Skill 在需要时会同时提供两者。

---

D3：反模式质量（15 分）

该 Skill 是否有有效的 NEVER 清单？

为什么这很重要：专家知识有一半是知道不该做什么。资深设计师看到白底上的紫色渐变会本能地皱眉——"太像 AI 生成的了。"这种对"绝对不该做什么"的直觉，来自踩过无数次的坑。

Claude 没有踩过这些坑。它不知道 Inter 字体被过度使用，不知道紫色渐变是 AI 生成内容的标志。好的 Skill 必须明确写出这些"绝对不要做的事"。

分数	标准
0-3	未提及任何反模式
4-7	泛泛的警告（"避免错误"、"要小心"、"考虑边界情况"）
8-11	具体的 NEVER 清单，并附有一些理由
12-15	专家级反模式，并说明 WHY —— 只有经验才能教会的那些

专家级反模式（具体 + 理由）：

NEVER use generic AI-generated aesthetics like:
- Overused font families (Inter, Roboto, Arial)
- Cliched color schemes (particularly purple gradients on white backgrounds)
- Predictable layouts and component patterns
- Default border-radius on everything

弱反模式（含糊、无理由）：

Avoid making mistakes.
Be careful with edge cases.
Don't write bad code.

检验方法：专家读了这份反模式清单后会说"是的，我是吃过苦头才学会的"吗？还是会说"这对每个人来说都是显而易见的"？

---

D4：规范符合度 —— 尤其是描述（15 分）

该 Skill 是否遵循官方格式要求？特别关注描述质量。

分数	标准
0-5	缺少 frontmatter 或格式无效
6-10	有 frontmatter，但描述模糊或不完整
11-13	frontmatter 有效，描述有 WHAT，但 WHEN 较弱
14-15	完美：全面的描述，包含 WHAT、WHEN 和触发关键词

Frontmatter 要求：

• name：小写，仅限字母数字 + 连字符，≤64 个字符
• description：最关键字段 —— 决定该 Skill 是否会被使用

---

为什么 description 是最重要的字段：

┌─────────────────────────────────────────────────────────────────────┐
│  SKILL ACTIVATION FLOW                                              │
│                                                                     │
│  User Request → Agent sees ALL skill descriptions → Decides which  │
│                 (only descriptions, not bodies!)     to activate    │
│                                                                     │
│  If description doesn't match → Skill NEVER gets loaded            │
│  If description is vague → Skill might not trigger when it should  │
│  If description lacks keywords → Skill is invisible to the Agent   │
└─────────────────────────────────────────────────────────────────────┘

残酷的事实：内容完美但描述糟糕的 Skill 毫无用处 —— 它永远不会被激活。description 是告诉 Agent“在这些情况下使用我”的唯一机会。

---

Description 必须回答三个问题：

1. WHAT：这个 Skill 做什么？（功能）
2. WHEN：应在什么情况下使用它？（触发场景）
3. KEYWORDS：哪些词应触发这个 Skill？（可搜索的词）

优秀的 description（包含全部三个要素）：

description: "Comprehensive document creation, editing, and analysis with support
for tracked changes, comments, formatting preservation, and text extraction.
When Claude needs to work with professional documents (.docx files) for:
(1) Creating new documents, (2) Modifying or editing content,
(3) Working with tracked changes, (4) Adding comments, or any other document tasks"

分析：

• WHAT：创建、编辑、分析、修订追踪、评论
• WHEN：“当 Claude 需要处理……用于：(1)…… (2)…… (3)……”
• KEYWORDS：.docx 文件、修订追踪、专业文档

糟糕的 description（缺少要素）：

description: "处理文档相关功能"

问题：

• WHAT：模糊（“文档相关功能”——具体是什么？）
• WHEN：缺失（Agent 应在何时使用它？）
• KEYWORDS：缺失（没有“.docx”，没有具体场景）

另一个糟糕的例子：

description: "A helpful skill for various tasks"

这毫无用处 —— Agent 完全不知道何时应激活它。

---

Description 质量检查清单：

• 列出具体能力（不只是“帮助处理 X”）
• 包含明确的触发场景（“Use when...”“When user asks for...”）
• 包含可搜索的关键词（文件扩展名、领域术语、动作动词）
• 足够具体，让 Agent 确切知道何时使用它
• 包含必须使用该 skill 的场景（不只是“可以使用”）

---

D5：渐进式披露（15 分）

该 Skill 是否实现了恰当的内容分层？

Skill 加载分为三层：

Layer 1: Metadata (always in memory)
         Only name + description
         ~100 tokens per skill

Layer 2: SKILL.md Body (loaded after triggering)
         Detailed guidelines, code examples, decision trees
         Ideal: < 500 lines

Layer 3: Resources (loaded on demand)
         scripts/, references/, assets/
         No limit

分数	标准
0-5	所有内容都堆在 SKILL.md 中（>500 行，无结构）
6-10	有 references，但不清楚何时加载它们
11-13	分层良好，存在 MANDATORY 触发条件
14-15	完美：决策树 + 显式触发条件 + “Do NOT Load” 指引

对于带有 references 目录的 Skill，检查加载触发质量：

触发质量	特征
差	references 列在末尾，没有加载指引
一般	有一些触发条件，但未嵌入工作流
好	MANDATORY 触发条件位于工作流步骤中
优秀	场景检测 + 条件触发 + “Do NOT Load”

加载问题：

Loading too little ◄─────────────────────────────────► Loading too much
- References sit unused                    - Wastes context space
- Agent doesn't know when to load          - Irrelevant info dilutes key content
- Knowledge is there but never accessed    - Unnecessary token overhead

良好的加载触发条件（嵌入工作流中）：

### Creating New Document

**MANDATORY - READ ENTIRE FILE**: Before proceeding, you MUST read
[`docx-js.md`](docx-js.md) (~500 lines) completely from start to finish.
**NEVER set any range limits when reading this file.**

**Do NOT load** `ooxml.md` or `redlining.md` for this task.

糟糕的加载触发条件（仅列出）：

## References
- docx-js.md - for creating documents
- ooxml.md - for editing
- redlining.md - for tracking changes

对于简单的 Skill（没有 references，<100 行）：根据简洁性和自包含性评分。

---

D6：自由度校准（15 分）

具体程度是否与任务的脆弱性相匹配？

不同任务需要不同程度的约束。这关乎让自由度与脆弱性相匹配。

分数	标准
0-5	严重不匹配（创意任务使用死板脚本，脆弱操作却含糊不清）
6-10	部分合适，存在一些不匹配
11-13	对大多数场景校准良好
14-15	全程自由度校准完美

自由度光谱：

任务类型	应具备	原因	示例 Skill
创意/设计	高自由度	存在多种有效方法，差异化就是价值	frontend-design
代码审查	中等自由度	有原则可循，但需要判断力	code-review
文件格式操作	低自由度	一个字节出错就会损坏文件，一致性至关重要	docx、xlsx、pdf

高自由度（基于文本的指令）：

Commit to a BOLD aesthetic direction. Pick an extreme: brutally minimal,
maximalist chaos, retro-futuristic, organic natural...

中等自由度（伪代码或参数化）：

Review priority:
1. Security vulnerabilities (must fix)
2. Logic errors (must fix)
3. Performance issues (should fix)
4. Maintainability (optional)

低自由度（具体脚本、精确步骤）：

**MANDATORY**: Use exact script in `scripts/create-doc.py`
Parameters: --title "X" --author "Y"
Do NOT modify the script.

测试方法：问自己“如果 Agent 犯错，后果是什么？”

• 后果严重 → 低自由度
• 后果轻微 → 高自由度

---

D7：模式识别（10 分）

该 Skill 是否遵循既有的官方模式？

通过分析 17 个官方 Skill，我们识别出 5 种主要设计模式：

模式	约行数	关键特征	示例	适用场景
Mindset	约 50	思维 > 技巧，强烈的 NEVER 清单，高自由度	frontend-design	需要品味的创意任务
Navigation	约 30	极简 SKILL.md，路由到子文件	internal-comms	多个不同场景
Philosophy	约 150	两步：Philosophy → Express，强调技艺	canvas-design	需要原创性的艺术/创作
Process	约 200	分阶段工作流，检查点，中等自由度	mcp-builder	复杂的多步骤项目
Tool	约 300	决策树，代码示例，低自由度	docx、pdf、xlsx	针对特定格式的精确操作

分数	标准
0-3	无可识别模式，结构混乱
4-6	部分遵循某种模式，但有显著偏差
7-8	模式清晰，仅有轻微偏差
9-10	对合适模式的应用炉火纯青

模式选择指南：

你的任务特征	推荐模式
需要品味和创造力	Mindset（约 50 行）
需要原创性和技艺质量	Philosophy（约 150 行）
有多个不同的子场景	Navigation（约 30 行）
复杂的多步骤项目	Process（约 200 行）
针对特定格式的精确操作	Tool（约 300 行）

---

D8：实用可用性（15 分）

Agent 是否真的能有效使用这个 Skill？

分数	标准
0-5	令人困惑、不完整、自相矛盾或未经测试的指导
6-10	可用但存在明显缺口
11-13	对常见情况有清晰指导
14-15	全面覆盖，包括边缘情况和错误处理

检查项：

• 决策树：对于多路径场景，是否有清晰指导说明该走哪条路径？
• 代码示例：它们真的能运行吗？还是只是会出错的伪代码？
• 错误处理：如果主要方法失败怎么办？是否提供了回退方案？
• 边缘情况：是否覆盖了不常见但现实存在的场景？
• 可操作性：Agent 能否立即行动，还是需要自己摸索？

良好的可用性（决策树 + 回退方案）：

| Task | Primary Tool | Fallback | When to Use Fallback |
|------|-------------|----------|----------------------|
| Read text | pdftotext | PyMuPDF | Need layout info |
| Extract tables | camelot-py | tabula-py | camelot fails |

**Common issues**:
- Scanned PDF: pdftotext returns blank → Use OCR first
- Encrypted PDF: Permission error → Use PyMuPDF with password

糟糕的可用性（含糊不清）：

Use appropriate tools for PDF processing.
Handle errors properly.
Consider edge cases.

---

评估时绝不要做的事

• 绝不仅因为 Skill“看起来很专业”或格式良好就给出高分
• 绝不忽视 token 浪费——每一段冗余内容都应导致扣分
• 绝不被篇幅所迷惑——一个 43 行的 Skill 可能胜过 500 行的 Skill
• 绝不跳过对决策树的心智测试——它们真的能导向正确选择吗？
• 绝不原谅对基础知识的讲解，借口“但它提供了有用的上下文”
• 绝不忽视缺失的反模式——如果没有 NEVER 列表，那是一个显著缺口
• 绝不假设所有流程都有价值——区分领域特定与通用内容
• 绝不低估 description 字段——糟糕的 description = Skill 永远不会被使用
• 绝不只把“何时使用”的信息放在正文中——Agent 在加载前只能看到 description

---

评估协议

步骤 1：第一遍——知识增量扫描

完整阅读 SKILL.md，并对每个部分发问：

“Claude 已经知道这个吗？”

将每个部分标记为：

• [E] 专家级：Claude 确实不知道——有增值
• [A] 激活：Claude 知道，但简短提醒有用——可接受
• [R] 冗余：Claude 肯定知道——应删除

计算大致比例：E:A:R

• 好的 Skill：>70% 专家级，<20% 激活，<10% 冗余
• 一般的 Skill：40-70% 专家级，激活内容较多
• 糟糕的 Skill：<40% 专家级，冗余内容较多

步骤 2：结构分析

[ ] Check frontmatter validity
[ ] Count total lines in SKILL.md
[ ] List all reference files and their sizes
[ ] Identify which pattern the Skill follows
[ ] Check for loading triggers (if references exist)

步骤 3：为每个维度打分

对于 8 个维度中的每一个：

1. 找到具体证据（引用相关行）
2. 给出分数，并用一行说明理由
3. 如果分数 < 满分，指出具体改进点

步骤 4：计算总分与评级

Total = D1 + D2 + D3 + D4 + D5 + D6 + D7 + D8
Max = 120 points

评级标准（基于百分比）：

评级	百分比	含义
A	90%+ (108+)	优秀——可投入生产的专家级 Skill
B	80-89% (96-107)	良好——需要小幅改进
C	70-79% (84-95)	合格——有明确的改进路径
D	60-69% (72-83)	低于平均——存在显著问题
F	<60% (<72)	较差——需要从根本上重新设计

步骤 5：生成报告

# Skill Evaluation Report: [Skill Name]

## Summary
- **Total Score**: X/120 (X%)
- **Grade**: [A/B/C/D/F]
- **Pattern**: [Mindset/Navigation/Philosophy/Process/Tool]
- **Knowledge Ratio**: E:A:R = X:Y:Z
- **Verdict**: [One sentence assessment]

## Dimension Scores

| Dimension | Score | Max | Notes |
|-----------|-------|-----|-------|
| D1: Knowledge Delta | X | 20 | |
| D2: Mindset vs Mechanics | X | 15 | |
| D3: Anti-Pattern Quality | X | 15 | |
| D4: Specification Compliance | X | 15 | |
| D5: Progressive Disclosure | X | 15 | |
| D6: Freedom Calibration | X | 15 | |
| D7: Pattern Recognition | X | 10 | |
| D8: Practical Usability | X | 15 | |

## Critical Issues
[List must-fix problems that significantly impact the Skill's effectiveness]

## Top 3 Improvements
1. [Highest impact improvement with specific guidance]
2. [Second priority improvement]
3. [Third priority improvement]

## Detailed Analysis
[For each dimension scoring below 80%, provide:
- What's missing or problematic
- Specific examples from the Skill
- Concrete suggestions for improvement]

---

常见失败模式

模式 1：教程式

Symptom: Explains what PDF is, how Python works, basic library usage
Root cause: Author assumes Skill should "teach" the model
Fix: Claude already knows this. Delete all basic explanations.
     Focus on expert decisions, trade-offs, and anti-patterns.

模式 2：堆砌式

Symptom: SKILL.md is 800+ lines with everything included
Root cause: No progressive disclosure design
Fix: Core routing and decision trees in SKILL.md (<300 lines ideal)
     Detailed content in references/, loaded on-demand

模式 3：孤立引用

Symptom: References directory exists but files are never loaded
Root cause: No explicit loading triggers
Fix: Add "MANDATORY - READ ENTIRE FILE" at workflow decision points
     Add "Do NOT Load" to prevent over-loading

模式 4：复选框式流程

Symptom: Step 1, Step 2, Step 3... mechanical procedures
Root cause: Author thinks in procedures, not thinking frameworks
Fix: Transform into "Before doing X, ask yourself..."
     Focus on decision principles, not operation sequences

模式 5：模糊警告

Symptom: "Be careful", "avoid errors", "consider edge cases"
Root cause: Author knows things can go wrong but hasn't articulated specifics
Fix: Specific NEVER list with concrete examples and non-obvious reasons
     "NEVER use X because [specific problem that takes experience to learn]"

模式 6：隐形 Skill

Symptom: Great content but skill rarely gets activated
Root cause: Description is vague, missing keywords, or lacks trigger scenarios
Fix: Description must answer WHAT, WHEN, and include KEYWORDS
     "Use when..." + specific scenarios + searchable terms

Example fix:
BAD:  "Helps with document tasks"
GOOD: "Create, edit, and analyze .docx files. Use when working with
       Word documents, tracked changes, or professional document formatting."

模式 7：位置错误

Symptom: "When to use this Skill" section in body, not in description
Root cause: Misunderstanding of three-layer loading
Fix: Move all triggering information to description field
     Body is only loaded AFTER triggering decision is made

模式 8：过度设计

Symptom: README.md, CHANGELOG.md, INSTALLATION_GUIDE.md, CONTRIBUTING.md
Root cause: Treating Skill like a software project
Fix: Delete all auxiliary files. Only include what Agent needs for the task.
     No documentation about the Skill itself.

模式 9：自由度不匹配

Symptom: Rigid scripts for creative tasks, vague guidance for fragile operations
Root cause: Not considering task fragility
Fix: High freedom for creative (principles, not steps)
     Low freedom for fragile (exact scripts, no parameters)

---

快速参考清单

┌─────────────────────────────────────────────────────────────────────────┐
│  SKILL EVALUATION QUICK CHECK                                           │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  KNOWLEDGE DELTA (most important):                                      │
│    [ ] No "What is X" explanations for basic concepts                   │
│    [ ] No step-by-step tutorials for standard operations                │
│    [ ] Has decision trees for non-obvious choices                       │
│    [ ] Has trade-offs only experts would know                           │
│    [ ] Has edge cases from real-world experience                        │
│                                                                         │
│  MINDSET + PROCEDURES:                                                  │
│    [ ] Transfers thinking patterns (how to think about problems)        │
│    [ ] Has "Before doing X, ask yourself..." frameworks                 │
│    [ ] Includes domain-specific procedures Claude wouldn't know         │
│    [ ] Distinguishes valuable procedures from generic ones              │
│                                                                         │
│  ANTI-PATTERNS:                                                         │
│    [ ] Has explicit NEVER list                                          │
│    [ ] Anti-patterns are specific, not vague                            │
│    [ ] Includes WHY (non-obvious reasons)                               │
│                                                                         │
│  SPECIFICATION (description is critical!):                              │
│    [ ] Valid YAML frontmatter                                           │
│    [ ] name: lowercase, ≤64 chars                                       │
│    [ ] description answers: WHAT does it do?                            │
│    [ ] description answers: WHEN should it be used?                     │
│    [ ] description contains trigger KEYWORDS                            │
│    [ ] description is specific enough for Agent to know when to use     │
│                                                                         │
│  STRUCTURE:                                                             │
│    [ ] SKILL.md < 500 lines (ideal < 300)                               │
│    [ ] Heavy content in references/                                     │
│    [ ] Loading triggers embedded in workflow                            │
│    [ ] Has "Do NOT Load" for preventing over-loading                    │
│                                                                         │
│  FREEDOM:                                                               │
│    [ ] Creative tasks → High freedom (principles)                       │
│    [ ] Fragile operations → Low freedom (exact scripts)                 │
│                                                                         │
│  USABILITY:                                                             │
│    [ ] Decision trees for multi-path scenarios                          │
│    [ ] Working code examples                                            │
│    [ ] Error handling and fallbacks                                     │
│    [ ] Edge cases covered                                               │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

---

元问题

在评估任何 Skill 时，始终回到这个根本问题：

“这个领域的专家看到这个 Skill 时，会不会说： ‘是的，这捕捉到了我花多年才学到的知识’？”

如果答案是肯定的 → 这个 Skill 具有真正的价值。 如果答案是否定的 → 它只是在压缩 Claude 已经知道的内容。

最好的 Skill 是压缩后的专家大脑——它们把设计师 10 年的审美积累压缩成 43 行，或把文档专家的操作经验压缩成 200 行的决策树。

被压缩的必须是 Claude 不具备的东西。否则，那就是垃圾压缩。

---

自我评估说明

这个 Skill（skill-judge）本身应当通过评估：

• 知识增量：提供了 Claude 无法自行生成的具体评估标准
• 思维方式：塑造如何思考 Skill 质量，而不只是核对清单条目
• 反模式："评估时绝不要做的事"部分列出了具体的禁止事项
• 规范性：有效的 frontmatter，并带有全面的描述
• 渐进式披露：自包含，无需外部引用
• 自由度：中等自由度，适合评估任务
• 模式：遵循 Tool 模式，并带有决策框架
• 可用性：清晰的协议、报告模板、快速参考

用这个 Skill 评估它自身，作为一次校准练习。