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

Skills はこれを変えます:

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 がすでに持っている知識を圧縮して書いていることになります。これはトークンの無駄遣いです。コンテキストウィンドウは、システムプロンプト、会話履歴、他の Skills、ユーザーのリクエストと共有される公共のリソースだからです。

ツールと 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 における 3 種類の知識

評価の際には、各セクションを次のように分類します:

種類	定義	扱い
エキスパート	Claude が本当に知らないこと	必ず残す ― これが Skill の価値である
アクティベーション	Claude は知っているが、思い浮かばないかもしれないこと	簡潔なら残す ― リマインダーとして機能する
冗長	Claude が確実に知っていること	削除すべき ― トークンを無駄にする

Skill 設計の妙は、エキスパートの内容を最大化し、アクティベーションは控えめに使い、冗長な内容は容赦なく取り除くことにあります。

---

評価の観点（合計 120 点）

D1: ナレッジデルタ（20 点） ― 中核となる観点

最も重要な観点です。その Skill は本物のエキスパート知識を加えているか？

スコア	基準
0-5	Claude が知っている基本を説明している（「X とは何か」、コードの書き方、標準ライブラリのチュートリアル）
6-10	混在: 一部のエキスパート知識が、自明な内容によって薄められている
11-15	ほとんどがエキスパート知識で、冗長さが最小限
16-20	純粋なナレッジデルタ ― すべての段落がそのトークンに見合っている

危険信号（即座にスコア 5 以下）:

• 「[基本概念] とは何か」というセクション
• 一般的な操作のステップバイステップのチュートリアル
• 一般的なライブラリの使い方の説明
• 一般的なベストプラクティス（「クリーンなコードを書く」「エラーを処理する」）
• 業界標準の用語の定義

良好な兆候（ナレッジデルタが高いことを示す指標）:

• 自明でない選択についての決定木（「X が失敗したら、Z という理由で Y を試す」）
• エキスパートだけが知るトレードオフ（「A は速いが、エッジケース C を B が扱える」）
• 実世界の経験から得られたエッジケース
• 「[自明でない理由] のため、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	理由を伴うエキスパートレベルのアンチパターン — 経験によってのみ得られる知見

エキスパートのアンチパターン（具体的 + 理由あり）：

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: 仕様準拠 — 特に description (15 点)

Skill は公式のフォーマット要件に従っているか？ 特に description の品質に注目します。

スコア	基準
0-5	frontmatter がない、または形式が不正
6-10	frontmatter はあるが、description が曖昧または不完全
11-13	frontmatter は有効で、description に WHAT はあるが WHEN が弱い
14-15	完璧: WHAT、WHEN、トリガーキーワードを備えた包括的な description

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   │
└─────────────────────────────────────────────────────────────────────┘

厳しい現実: 内容が完璧でも description が貧弱な Skill は役に立たず、決して有効化されません。description は、エージェントに「こうした状況で私を使ってください」と伝える唯一の機会です。

---

description は 3 つの問いに答える必要があります:

1. WHAT: この Skill は何をするのか？（機能）
2. WHEN: どのような状況で使うべきか？（トリガーとなる場面）
3. KEYWORDS: どのような用語で この Skill が起動されるべきか？（検索可能な用語）

優れた description（3 つの要素をすべて満たす）:

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: 欠落（エージェントはいつこれを使うべきか？）
• KEYWORDS: 欠落（「.docx」がなく、具体的な場面もない）

別の貧弱な例:

description: "A helpful skill for various tasks"

これは役に立ちません。エージェントはいつこれを有効化すべきか全く判断できません。

---

description 品質チェックリスト:

• 具体的な機能を列挙している（単に「X を支援します」ではない）
• 明示的なトリガー場面を含んでいる（「次の場合に使用」「ユーザーが…を求めたとき」など）
• 検索可能なキーワードを含んでいる（ファイル拡張子、ドメイン用語、動作を表す動詞）
• エージェントがいつ使うべきかを正確に判断できるほど具体的である
• この Skill を「使用できる」だけでなく「必ず使用すべき」場面を含んでいる

---

D5: 段階的開示 (15 点)

Skill は適切なコンテンツの階層化を実装しているか？

Skill の読み込みは 3 つの階層で構成されます:

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	完璧: 判断ツリー + 明示的なトリガー + 「読み込まない場合」のガイダンス

references ディレクトリを持つ Skillについては、読み込みトリガーの品質を確認します:

トリガーの品質	特徴
貧弱	references が末尾に列挙されているだけで、読み込みのガイダンスがない
普通	トリガーはあるが、ワークフローに組み込まれていない
良好	ワークフローの手順に MANDATORY のトリガーが組み込まれている
優秀	場面の検出 + 条件付きトリガー + 「読み込まない場合」の指示がある

読み込みの問題:

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
ファイル形式の操作	低い自由度	1バイトの誤りでファイルが破損し、一貫性が重要	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.

テスト: 「エージェントが間違えた場合、その結果はどうなるか？」と問いかけます。

• 結果が重大 → 低い自由度
• 結果が軽微 → 高い自由度

---

D7: パターン認識（10点）

そのSkillは確立された公式パターンに従っているか？

17の公式Skillを分析した結果、5つの主要な設計パターンを特定しました。

パターン	約行数	主な特徴	例	使用する場面
マインドセット	約50	技法より思考を重視、強力なNEVERリスト、高い自由度	frontend-design	審美眼が求められる創造的なタスク
ナビゲーション	約30	最小限のSKILL.md、サブファイルへルーティング	internal-comms	複数の異なるシナリオがある場合
フィロソフィー	約150	2段階：哲学 → 表現、職人技を重視	canvas-design	独創性が求められる芸術/創作
プロセス	約200	フェーズ化されたワークフロー、チェックポイント、中程度の自由度	mcp-builder	複雑な多段階プロジェクト
ツール	約300	決定木、コード例、低い自由度	docx, pdf, xlsx	特定の形式に対する精密な操作

スコア	基準
0-3	認識可能なパターンがなく、構造が混乱している
4-6	パターンに部分的に従っているが、大きな逸脱がある
7-8	明確なパターンがあり、小さな逸脱のみ
9-10	適切なパターンを見事に適用している

パターン選択ガイド:

タスクの特徴	推奨パターン
審美眼と創造性が必要	マインドセット（約50行）
独創性と職人技の品質が必要	フィロソフィー（約150行）
複数の異なるサブシナリオがある	ナビゲーション（約30行）
複雑な多段階プロジェクト	プロセス（約200行）
特定の形式に対する精密な操作	ツール（約300行）

---

D8: 実用的な使いやすさ（15点）

エージェントはこのSkillを実際に効果的に使えるか？

スコア	基準
0-5	分かりにくい、不完全、矛盾している、またはテストされていない指示
6-10	使用可能だが、目立つ欠落がある
11-13	一般的なケースに対して明確な指示がある
14-15	エッジケースやエラー処理を含む包括的なカバレッジ

確認事項:

• 決定木: 複数の経路があるシナリオで、どの経路を取るべきかの明確な指針があるか？
• コード例: 実際に動作するか？それとも壊れてしまう擬似コードか？
• エラー処理: 主要なアプローチが失敗した場合どうするか？フォールバックは用意されているか？
• エッジケース: 珍しいが現実的なシナリオがカバーされているか？
• 実行可能性: エージェントはすぐに行動できるか、それとも何を行うかを自ら考え出す必要があるか？

良好な使いやすさ（決定木 + フォールバック）:

| 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.

---

評価時に絶対にしてはいけないこと

• 絶対に「プロフェッショナルに見える」とか、整形されているというだけで高いスコアを付けないでください
• 絶対にトークンの無駄を見逃さないでください。冗長な段落はすべて減点対象としてください
• 絶対に長さに感心しないでください。43行のSkillが500行のSkillを上回ることもあります
• 絶対に判断ツリーを頭の中で検証することを省略しないでください。それらは本当に正しい選択に導くでしょうか？
• 絶対に「ただし有用な文脈を提供している」という理由で、基本事項の説明を大目に見ないでください
• 絶対に欠けているアンチパターンを見過ごさないでください。NEVERリストがない場合、それは重大な欠落です
• 絶対にすべての手順に価値があると決めつけないでください。ドメイン固有のものと汎用的なものを区別してください
• 絶対にdescriptionフィールドを過小評価しないでください。descriptionが不十分であれば、そのSkillは決して使われません
• 絶対に「いつ使うか」の情報を本文だけに書かないでください。Agentは読み込み前にdescriptionしか見ません

---

評価プロトコル

ステップ1：一次スキャン — 知識差分スキャン

SKILL.mdを最後まで読み、各セクションについて次の問いを立ててください。

「Claudeはこれをすでに知っているか？」

各セクションに次のいずれかの印を付けてください：

• [E] Expert（専門性）：Claudeが本当に知らない内容 — 付加価値がある
• [A] Activation（想起）：Claudeは知っているが、短い想起として有用 — 許容範囲
• [R] Redundant（冗長）：Claudeが確実に知っている内容 — 削除すべき

おおよその比率 E:A:R を算出してください

• 良いSkill：Expertが70%超、Activationが20%未満、Redundantが10%未満
• 普通のSkill：Expertが40〜70%、Activationが多い
• 悪いSkill：Expertが40%未満、Redundantが多い

ステップ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を見て、次のように言うだろうか： 『はい、これは私が何年もかけて学んだ知識を捉えている』と？」

はい → 本物の価値がある。 いいえ → Claudeがすでに知っていることを圧縮しているにすぎない。

最良のSkillは圧縮された専門家の知見です。デザイナーが10年かけて培った美的感覚を43行に凝縮したり、ドキュメントの専門家の運用経験を200行の判断ツリーに凝縮したりします。

圧縮される内容は、Claudeが持っていないものでなければなりません。そうでなければ、それは単なるゴミの圧縮です。

---

自己評価に関する注記

この Skill（skill-judge）は、それ自体が評価を通過している必要があります。

• Knowledge Delta: Claude が自力では生成できない、具体的な評価基準を提供していること
• Mindset: チェックリスト項目だけでなく、Skill の品質についての考え方を形成すること
• Anti-Patterns: 具体的な禁止事項を記載した「評価時に絶対にしないこと（NEVER Do When Evaluating）」セクションがあること
• Specification: 包括的な description を備えた有効なフロントマターがあること
• Progressive Disclosure: 自己完結しており、外部参照を必要としないこと
• Freedom: 評価タスクに適した中程度の自由度であること
• Pattern: 判断フレームワークを備えた Tool パターンに従っていること
• Usability: 明確な手順、レポートテンプレート、クイックリファレンスがあること

校正のための演習として、この Skill をそれ自身に対して評価してください。