スキルジャッジ

17以上の公式事例から導き出された公式仕様とパターンに照らしてエージェントスキルを評価します。

---

コア理念

スキルとは何か?

スキルはチュートリアルではありません。スキルは知識の外部化メカニズムです。

従来のAI知識はモデルパラメータに閉じ込められています。新しい能力を教えるには:

従来の方法: データ収集 → GPU クラスタ → トレーニング → 新バージョンをデプロイ
コスト: $10,000 - $1,000,000+
期間: 数週間から数ヶ月

スキルはこれを変えます:

スキル: SKILL.md を編集 → 保存 → 次の呼び出し時に効果を発揮
コスト: $0
期間: 即座に反映

これは「AIをトレーニングする」から「AIを教育する」へのパラダイムシフトです。トレーニングが不要なホットスワップ可能なLoRAアダプタのようなものです。Markdownファイルを自然言語で編集すれば、モデルの動作が変わります。

コア公式

優良スキル = エキスパート専有知識 − Claudeが既に知っていること

スキルの価値は知識デルタで測定されます。すなわち、それが提供するものとモデルが既に知っていることの間のギャップです。

• エキスパート専有知識: 意思決定木、トレードオフ、エッジケース、アンチパターン、ドメイン固有の思考フレームワーク — 数年の経験を積み重ねて初めて得られるもの
• Claudeが既に知っていること: 基本概念、標準ライブラリの使用方法、一般的なプログラミングパターン、一般的なベストプラクティス

スキルが「PDFとは何か」や「ループの書き方」を説明している場合、それはClaudeが既に持つ知識を圧縮しているのです。これはトークン浪費 — コンテキストウィンドウはシステムプロンプト、会話履歴、他のスキル、ユーザーリクエストで共有されるパブリックリソースです。

ツール対スキル

概念	本質	機能	例
ツール	モデルができること	アクションを実行	bash、read_file、write_file、WebSearch
スキル	モデルが何をすべきかを知っていること	意思決定をガイド	PDF処理、MCP構築、フロントエンド設計

ツールは機能の境界線を定義します。bashツールがないと、モデルはコマンドを実行できません。 スキルは知識を注入します。フロントエンド設計スキルがないと、モデルは汎用的なUIを生成します。

公式:

汎用エージェント + 優れたスキル = ドメインエキスパートエージェント

同じClaudeモデルでも、読み込まれるスキルが異なると、異なるエキスパートになります。

スキル内の知識の3つのタイプ

評価時に各セクションを分類してください:

タイプ	定義	扱い
エキスパート	Claudeが本当に知らないもの	保持する必要があります — これがスキルの価値
アクティベーション	Claudeは知っていても思いつかないもの	短ければ保持 — リマインダーとして機能
冗長	Claudeが確実に知っているもの	削除すべき — トークンを浪費

スキル設計の芸術は、エキスパートコンテンツを最大化し、アクティベーションは控えめに使用し、冗長性を容赦なく排除することです。

---

評価ディメンション(合計120ポイント)

D1: 知識デルタ(20ポイント) — コアディメンション

最も重要なディメンション。スキルは本当のエキスパート知識を追加しているか?

スコア	基準
0-5	Claudeが知っている基礎を説明 (Xとは何か、コードの書き方、標準ライブラリチュートリアル)
6-10	混合: エキスパート知識が明らかなコンテンツで薄まっている
11-15	主にエキスパート知識で冗長性は最小限
16-20	純粋な知識デルタ — すべての段落がトークンに見合う価値

レッドフラグ(即座にスコア≤5):

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

グリーンフラグ(高い知識デルタの指標):

• 非自明の選択肢のための意思決定木(「XがY失敗するとき、Z理由でYを試す」)
• エキスパートしか知らないトレードオフ(「Aは速いがBはエッジケースCを処理」)
• 実務経験からのエッジケース
• 「Xを決してしてはいけない — [非自明な理由]」
• ドメイン固有の思考フレームワーク

評価質問:

1. 各セクションについて: 「Claudeはこれを既に知っているか?」
2. 何かを説明している場合: 「これはClaudeに説明しているのか、それともClaudeのために説明しているのか?」
3. エキスパート対アクティベーション対冗長の段落数をカウント

---

D2: マインドセット+適切な手順(15ポイント)

スキルは思考パターンと必要なドメイン固有手順の両方をエキスパートから転送するか?

専門家と初心者の違いは「操作方法を知る」ことではなく、「問題についてどう考えるか」です。しかし、Claudeがドメイン固有の手順的知識に欠ける場合、思考パターンだけでは十分ではありません。

主要な区別:

タイプ	例	価値
思考パターン	「デザインする前に、これを記憶に残すものは何かと自問する」	高 — 意思決定を形作る
ドメイン固有手順	「OOXML ワークフロー: 展開 → XML編集 → 検証 → パック」	高 — Claudeは知らないかもしれない
汎用手順	「ステップ1: ファイルを開く、ステップ2: 編集、ステップ3: 保存」	低 — Claudeは既に知っている

スコア	基準
0-3	Claudeが既に知っているジェネリック手順のみ
4-7	ドメイン手順を持つが思考フレームワークが不足
8-11	良好なバランス: 思考パターン + ドメイン固有ワークフロー
12-15	エキスパートレベル: 思考を形作り、かつClaudeが知らない手順を提供

価値のある手順として数えるもの:

• Claudeが訓練を受けていないワークフロー(新しいツール、独自システム)
• 非自明な正しい順序(例: パック後ではなく、パック前に検証)
• 見落としやすい重要なステップ(例: 「編集後に式を再計算する必要があります」)
• ドメイン固有シーケンス(例: MCPサーバーの4段階開発プロセス)

冗長な手順として数えるもの:

• ジェネリックファイル操作(オープン、読み込み、書き込み、保存)
• 標準的なプログラミングパターン(ループ、条件分岐、エラーハンドリング)
• よくドキュメント化されている一般的なライブラリ使用法

エキスパート思考パターンは以下のようです:

[アクション]の前に、自問してください:
- **目的**: これは何の問題を解決しますか? 誰がそれを使いますか?
- **制約**: 隠れた要件は何ですか?
- **差別化**: このソリューションを記憶に残すものは何ですか?

価値のあるドメイン手順は以下のようです:

### 編集追跡ワークフロー(Claudeはこのシーケンスを知りません)
1. markdownに変換: `pandoc --track-changes=all`
2. テキストをXMLにマップ: document.xmlのテキストをgrepで検索
3. バッチで変更を実装: 3-10個のバッチ
4. パックして検証: すべての変更が適用されたことを確認

冗長なジェネリック手順は以下のようです:

ステップ1: ファイルを開く
ステップ2: セクションを見つける
ステップ3: 変更する
ステップ4: 保存してテストする

テスト:

1. Claudeに「何を考えるか」を伝えているか? (思考パターン)
2. Claudeに「知らないことをどうするか」を伝えているか? (ドメイン手順)

優良スキルは必要に応じて両方を提供します。

---

D3: アンチパターン品質(15ポイント)

スキルは効果的なNEVERリストを持っているか?

なぜこれが重要か: エキスパート知識の半分は「何をしてはいけないか」を知ることです。シニアデザイナーは白い背景に紫のグラデーションを見て、本能的に縮み上がります — 「AI生成っぽすぎる」。この「絶対にしてはいけないこと」に対する直感は、数え切れないほどの地雷を踏んだことから来ています。

Claudeはこれらの地雷を踏んでいません。Interフォントが使い古されていることを知りませんし、紫のグラデーションがAI生成コンテンツの署名であることを知りませんし。優良スキルはこれらの「絶対的禁止」を明示的に述べる必要があります。

スコア	基準
0-3	アンチパターンが言及されていない
4-7	ジェネリック警告(「エラーを避ける」「注意する」「エッジケースを検討する」)
8-11	理由付きの具体的なNEVERリスト
12-15	WHY付きのエキスパートグレードアンチパターン — 経験だけが教えるもの

エキスパートアンチパターン(具体的 + 理由):

以下のようなジェネリックなAI生成美学を使ってはいけません:
- 使い古されたフォントファミリー(Inter、Roboto、Arial)
- ありきたりなカラースキーム(特に白い背景上の紫グラデーション)
- 予測可能なレイアウトとコンポーネントパターン
- すべてのものへのデフォルトボーダーラディウス

弱いアンチパターン(曖昧、理由がない):

間違いを避けてください。
エッジケースに注意してください。
悪いコードを書かないでください。

テスト: エキスパートがアンチパターンリストを読んで「はい、私は大変な思いをしてこれを学びました」と言うか、それとも「これは誰もが知っている」と言うか?

---

D4: 仕様準拠 — 特に説明(15ポイント)

スキルは公式フォーマット要件に従っているか? 説明の品質に特に焦点を当てます。

スコア	基準
0-5	フロントマターがない、または形式が無効
6-10	フロントマターはあるが説明が曖昧または不完全
11-13	有効なフロントマター、説明は「何」を持つが「いつ」が弱い
14-15	完璧: WHATとWHENとトリガーキーワードを含む包括的な説明

フロントマター要件:

• name: 小文字、英数字 + ハイフンのみ、≤64文字
• description: 最も重要なフィールド — スキルが使用されるかどうかを決定

---

説明がなぜ最も重要なフィールドなのか:

┌─────────────────────────────────────────────────────────────────────┐
│  スキルアクティベーションフロー                                       │
│                                                                     │
│  ユーザーリクエスト → エージェントがすべてのスキル説明を見る →     │
│                   (本文ではなく説明のみ!)   どれを         │
│                                      有効化するか        │
│                                      判定           │
│                                                                     │
│  説明が一致しない → スキルは決してロードされない                    │
│  説明が曖昧 → スキルが必要なときにトリガーしないかもしれない        │
│  説明がキーワード不足 → スキルはエージェントに見えない               │
└─────────────────────────────────────────────────────────────────────┘

厳しい真実: 完璧なコンテンツを持つが説明が悪いスキルは役に立たない — それは決して有効化されません。説明は「このような状況で使ってください」をエージェントに伝える唯一のチャンスです。

---

説明は3つの質問に答える必要があります:

1. WHAT: このスキルは何をしますか? (機能)
2. WHEN: どのような状況で使うべきですか? (トリガーシナリオ)
3. KEYWORDS: どの用語がこのスキルをトリガーすべきですか? (検索可能な用語)

優れた説明(3つの要素をすべて含む):

description: "プロフェッショナルドキュメント(.docxファイル)を操作する必要がある場合の
包括的なドキュメント作成、編集、分析。トラッキング変更、コメント、フォーマット保持、
テキスト抽出をサポート。以下のような場合に使用: (1)新しいドキュメントを作成、
(2)コンテンツを編集、(3)トラッキング変更を使用、(4)コメントを追加、
またはその他のドキュメントタスク"

分析:

• WHAT: 作成、編集、分析、トラッキング変更、コメント
• WHEN: 「プロフェッショナルドキュメントを操作する必要がある場合」
• KEYWORDS: .docxファイル、トラッキング変更、プロフェッショナルドキュメント

悪い説明(要素が不足):

description: "ドキュメント関連の機能を処理"

問題:

• WHAT: 曖昧 (「ドキュメント関連機能」— 具体的には何か?)
• WHEN: 不足 (エージェントがいつ使うべきか知らない)
• KEYWORDS: 不足 (".docx"や具体的なシナリオがない)

別の悪い例:

description: "様々なタスクに役立つスキル"

これは役に立たない — エージェントは使用を決定することができません。

---

説明品質チェックリスト:

• 具体的な機能をリストしている(単に「Xに役立つ」ではなく)
• 明示的なトリガーシナリオが含まれている(「使用する場合」、「ユーザーが...を求める場合」)
• 検索可能なキーワードが含まれている(ファイル拡張子、ドメイン用語、動詞)
• エージェントが「このスキルを使う正確なタイミング」を知るのに十分な具体性
• スキルを「使うべき」状況を含む(単に「使用できる」ではなく)

---

D5: プログレッシブディスクロージャー(15ポイント)

スキルは適切なコンテンツ層化を実装しているか?

スキル読み込みには3つの層があります:

層1: メタデータ(常にメモリ内)
     名前 + 説明のみ
     ~スキルあたり100トークン

層2: SKILL.md本文(トリガー後にロード)
     詳細なガイドライン、コード例、意思決定木
     理想: < 500行

層3: リソース(必要に応じてロード)
     scripts/、references/、assets/
     制限なし

スコア	基準
0-5	すべてがSKILL.mdに吐き出されている(>500行、構造なし)
6-10	参考資料はあるが、いつロードするか不明確
11-13	優れた層化と義務的なトリガーが存在
14-15	完璧: 意思決定木 + 明示的なトリガー + 「ロードしないでください」ガイダンス

参考資料ディレクトリを持つスキルの場合、読み込みトリガー品質を確認:

トリガー品質	特徴
悪い	参考資料は最後にリストされており、読み込みガイダンスがない
中程度	一部のトリガーがあるが、ワークフロー内に組み込まれていない
良い	ワークフロー手順内に義務的なトリガー
優秀	シナリオ検出 + 条件付きトリガー + 「ロードしないでください」

読み込みの問題:

読み込みが少なすぎる ◄───────────────────► 読み込みが多すぎる
- 参考資料は未使用のまま                - コンテキストスペースを浪費
- エージェントはいつロードするか知らない   - 関係のない情報がキーコンテンツを薄める
- 知識がそこにあるが決してアクセスされない  - 不要なトークンオーバーヘッド

優れた読み込みトリガー(ワークフローに組み込み):

### 新しいドキュメントを作成

**義務的 — ファイル全体を読んでください**: 進める前に、
[`docx-js.md`](docx-js.md) (~500行)を最初から最後まで完全に読む必要があります。
**このファイルを読む場合、範囲制限を絶対に設定しないでください。**

**ロードしないでください**: このタスクでは`ooxml.md`または`redlining.md`。

悪い読み込みトリガー(単にリスト):

## 参考資料
- docx-js.md — ドキュメント作成用
- ooxml.md — 編集用
- redlining.md — 変更追跡用

シンプルなスキルの場合(参考資料なし、<100行): 簡潔さと自己完結性に基づいてスコア。

---

D6: 自由度の検定(15ポイント)

仕様の詳細さのレベルはタスクの脆弱性に適切か?

異なるタスクは異なるレベルの制約が必要です。これは自由度と脆弱性のマッチングに関するものです。

スコア	基準
0-5	大きく不一致(クリエイティブなタスクに厳密なスクリプト、脆弱な操作には曖昧)
6-10	部分的に適切、いくつかの不一致
11-13	ほとんどのシナリオで優れた検定
14-15	全体的に完璧な自由度検定

自由度スペクトラム:

タスクタイプ	持つべき特徴	理由	スキル例
クリエイティブ/デザイン	高い自由度	複数の有効なアプローチ、差別化は価値	フロントエンド設計
コードレビュー	中程度の自由度	原則は存在するが判断が必要	コードレビュー
ファイル形式操作	低い自由度	1バイトの間違いでファイルが破損、一貫性が重要	docx、xlsx、pdf

高い自由度(テキストベースの指示):

大胆な美的方向にコミットしてください。極端なものを選んでください:
非常に洗練された、最大限主義的なカオス、レトロフューチャー、有機的な自然...

中程度の自由度(疑似コードまたはパラメータ化):

レビューの優先度:
1. セキュリティ脆弱性(修正が必須)
2. ロジックエラー(修正が必須)
3. パフォーマンスの問題(修正が望ましい)
4. 保守性(オプション)

低い自由度(具体的なスクリプト、正確なステップ):

**義務的**: `scripts/create-doc.py`の正確なスクリプトを使用
パラメータ: --title "X" --author "Y"
スクリプトを変更しないでください。

テスト: 「エージェントが間違いを犯した場合、結果はどうなるか?」と尋ねる

• 高い結果 → 低い自由度
• 低い結果 → 高い自由度

---

D7: パターン認識(10ポイント)

スキルは確立された公式パターンに従っているか?

17の公式スキルを分析することで、5つの主なデザインパターンが確認されました:

パターン	~行数	主要特性	例	使用する場合
マインドセット	~50	テクニック>思考、強力なNEVERリスト、高い自由度	フロントエンド設計	味が必要なクリエイティブタスク
ナビゲーション	~30	最小限のSKILL.md、サブファイルへのルーティング	社内コミュニケーション	複数の異なるシナリオ
哲学	~150	2ステップ: 哲学 → 表現、独創性を強調	キャンバス設計	独創性が必要なアート/作成
プロセス	~200	フェーズ化されたワークフロー、チェックポイント、中程度の自由度	MCPビルダー	複雑なマルチステッププロジェクト
ツール	~300	意思決定木、コード例、低い自由度	docx、pdf、xlsx	特定の形式に対する正確な操作

スコア	基準
0-3	認識可能なパターンがなく、構造が混乱している
4-6	部分的にパターンに従うが、かなりの逸脱
7-8	明確なパターン、マイナーな逸脱
9-10	適切なパターンの巧みな適用

パターン選択ガイド:

タスク特性	推奨パターン
味と創造性が必要	マインドセット(~50行)
独創性と職人的品質が必要	哲学(~150行)
複数の明確なサブシナリオ	ナビゲーション(~30行)
複雑なマルチステッププロジェクト	プロセス(~200行)
特定形式に対する正確な操作	ツール(~300行)

---

D8: 実用性(15ポイント)

エージェントはこのスキルを効果的に使用できるか?

スコア	基準
0-5	混乱、不完全、矛盾、またはテストされていないガイダンス
6-10	使用可能だが顕著なギャップあり
11-13	一般的なケースに対する明確なガイダンス
14-15	エッジケースとエラーハンドリングを含む包括的なカバレッジ

チェック項目:

• 意思決定木: マルチパスシナリオの場合、どのパスをたどるかについての明確なガイダンス?
• コード例: 実際に動作しているか? それとも壊れた疑似コードか?
• エラーハンドリング: メインアプローチが失敗した場合はどうなるか? フォールバックが提供されているか?
• エッジケース: 珍しいが現実的なシナリオがカバーされているか?
• 実行可能性: エージェントはすぐに行動できるか、それとも物事を理解する必要があるか?

優れた実用性(意思決定木 + フォールバック):

| タスク | プライマリツール | フォールバック | フォールバックをいつ使うか |
|------|-----------|-----------|-----------|
| テキストを読む | pdftotext | PyMuPDF | レイアウト情報が必要 |
| テーブルを抽出 | camelot-py | tabula-py | cametが失敗 |

**一般的な問題**:
- スキャンされたPDF: pdftotextが空白を返す → OCRを最初に使用
- 暗号化されたPDF: パーミッションエラー → パスワード付きPyMuPDFを使用

貧弱な実用性(曖昧):

PDF処理に適切なツールを使用してください。
エラーを適切に処理してください。
エッジケースを検討してください。

---

評価する際に決してしないこと

• 決して「プロフェッショナルに見える」「よくフォーマットされている」だけで高スコアを与えないこと
• 決してトークン浪費を無視しないこと — すべての冗長な段落は減点につながるべき
• 決して長さだけで感動しないこと — 43行のスキルは500行のスキルより優れるかもしれない
• 決して意思決定木を精神的にテストせずにスキップしないこと — 実際に正しい選択肢に導いているか?
• 決して「役立つコンテキストを提供する」として基礎説明を許さないこと
• 決してアンチパターンの欠落を見落とさないこと — NULLリストがない場合、それは大きなギャップ
• 決してすべての手順が価値があると仮定しないこと — ドメイン固有と汎用を区別する
• 決して説明フィールドを過小評価しないこと — 説明が悪い = スキルが決して使われない
• 決して「いつ使うか」情報を本文のみに置かないこと — エージェントはロード前に説明のみを見る

---

評価プロトコル

ステップ1: 最初のパス — 知識デルタスキャン

SKILL.mdを完全に読み、各セクションについて以下の質問をしてください:

「Claudeはこれを既に知っているか?」

各セクションをマーク:

• [E] エキスパート: Claudeが本当に知らない — 価値追加
• [A] アクティベーション: Claudeは知っているが短いリマインダーは有用 — 許容可能
• [R] 冗長: Claudeが確実に知っている — 削除すべき

大まかな比率を計算: E:A:R

• 優良スキル: >70% エキスパート、<20% アクティベーション、<10% 冗長
• 中程度スキル: 40-70% エキスパート、高いアクティベーション
• 悪いスキル: <40% エキスパート、高い冗長

ステップ2: 構造分析

[ ] フロントマター有効性をチェック
[ ] SKILL.md内の合計行数をカウント
[ ] すべての参考ファイルとそのサイズをリストアップ
[ ] スキルが従うパターンを特定
[ ] 読み込みトリガーをチェック(参考資料がある場合)

ステップ3: 各ディメンションをスコア

各8つのディメンションについて:

1. 具体的な証拠を見つける(関連する行を引用)
2. 1行の正当化でスコアを割り当てる
3. スコア < 最大の場合、具体的な改善を記録

ステップ4: 合計を計算してグレード

合計 = D1 + D2 + D3 + D4 + D5 + D6 + D7 + D8
最大 = 120ポイント

グレードスケール(パーセンテージベース):

グレード	パーセンテージ	意味
A	90%以上(108+)	優秀 — 本番環境対応のエキスパートスキル
B	80-89% (96-107)	優良 — 軽微な改善が必要
C	70-79% (84-95)	適切 — 明確な改善パス
D	60-69% (72-83)	平均以下 — 重大な問題
F	<60% (<72)	不良 — 根本的な再設計が必要

ステップ5: レポートを生成

# スキル評価レポート: [スキル名]

## 概要
- **総スコア**: X/120 (X%)
- **グレード**: [A/B/C/D/F]
- **パターン**: [マインドセット/ナビゲーション/哲学/プロセス/ツール]
- **知識比**: E:A:R = X:Y:Z
- **評決**: [スキルの有効性に関する1文の評価]

## ディメンションスコア

| ディメンション | スコア | 最大 | 備考 |
|----------|-------|-----|------|
| D1: 知識デルタ | X | 20 | |
| D2: マインドセット対メカニクス | X | 15 | |
| D3: アンチパターン品質 | X | 15 | |
| D4: 仕様準拠 | X | 15 | |
| D5: プログレッシブディスクロージャー | X | 15 | |
| D6: 自由度検定 | X | 15 | |
| D7: パターン認識 | X | 10 | |
| D8: 実用性 | X | 15 | |

## 重大な問題
[スキルの有効性に大きな影響を与える必須修正の問題をリストアップ]

## トップ3の改善
1. [具体的なガイダンス付き最高インパクト改善]
2. [第2優先度改善]
3. [第3優先度改善]

## 詳細分析
[80%未満でスコアリングされた各ディメンションについて:
- 何が不足しているか、または問題があるか
- スキルからの具体的な例
- 改善のための具体的な提案]

---

よくある失敗パターン

パターン1: チュートリアル

症状: PDFとは何か、Pythonの使い方、基本的なライブラリ使用方法を説明
根本原因: スキルが「教育する」べきだと著者が想定
修正: Claudeはこれを既に知っています。基本説明をすべて削除。
     エキスパート決定、トレードオフ、アンチパターンに焦点を当てる。

パターン2: ダンプ

症状: SKILL.mdが800行以上で、すべてが含まれている
根本原因: プログレッシブディスクロージャー設計がない
修正: コアルーティングと意思決定木をSKILL.mdに(<300行理想)
     詳細コンテンツはreferences/に、オンデマンドでロード

パターン3: オーファン参考資料

症状: 参考資料ディレクトリが存在するがファイルが決してロードされない
根本原因: 明示的な読み込みトリガーがない
修正: ワークフロー決定ポイントで「このファイル全体を読むことが義務的」を追加
     過度なロードを防ぐために「ロードしないでください」を追加

パターン4: チェックボックス手順

症状: ステップ1、ステップ2、ステップ3... 機械的な手順
根本原因: 著者が手順で考えている、思考フレームワークではなく
修正: 「Xをする前に、自問してください...」に変換
     操作シーケンスではなく決定原則に焦点を当てる

パターン5: 曖昧な警告

症状: 「注意してください」「エラーを避ける」「エッジケースを検討する」
根本原因: 著者は物事が間違う可能性があることを知っているが、具体性を示していない
修正: 具体的なNEVERリストと具体的な例と非自明な理由
     「決してXをしないでください — [経験を積むのに特定の時間がかかる問題]」

パターン6: 見えないスキル

症状: 優れたコンテンツだが、スキルはめったに有効化されない
根本原因: 説明は曖昧、キーワード不足、またはトリガーシナリオ欠落
修正: 説明は「何」「いつ」「キーワード」に答える必要があります
     「使用する場合...」+具体的なシナリオ +検索可能な用語

修正例:
悪い:  「ドキュメントタスクに役立つ」
良い: 「.docxファイルを作成、編集、分析。Word文書、トラッキング変更、
     またはプロフェッショナルドキュメント形式で作業する場合に使用。」

パターン7: 間違った場所

症状: ボディに「このスキルをいつ使うか」セクションがある
根本原因: 3層読み込みの誤解
修正: すべてのトリガー情報を説明フィールドに移動
     ボディは「トリガー後に」ロードされます

パターン8: 過度に設計

症状: README.md、CHANGELOG.md、INSTALLATION_GUIDE.md、CONTRIBUTING.md
根本原因: スキルをソフトウェアプロジェクトとして扱う
修正: 補助ファイルをすべて削除。エージェントがタスクのために必要なもののみ。
     スキル自体についてのドキュメントはありません。

パターン9: 自由度の不一致

症状: クリエイティブなタスクには厳密なスクリプト、脆弱な操作には曖昧なガイダンス
根本原因: タスク脆弱性を考慮していない
修正: クリエイティブなために高い自由度(原則、ステップではなく)
     脆弱性のために低い自由度(正確なスクリプト、パラメータなし)

---

クイックリファレンスチェックリスト

┌─────────────────────────────────────────────────────────────────────────┐
│  スキル評価クイックチェック                                             │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  知識デルタ(最も重要):                                                  │
│    [ ] 基本概念のための「Xとは」説明なし                                 │
│    [ ] 標準操作のステップバイステップチュートリアルなし                  │
│    [ ] 非自明な選択肢のための意思決定木がある                            │
│    [ ] エキスパートのみが知るトレードオフがある                          │
│    [ ] 実務経験からのエッジケースがある                                  │
│                                                                         │
│  マインドセット+手順:                                                   │
│    [ ] 思考パターンを転送(問題について考え方)                            │
│    [ ] 「Xをする前に、自問してください...」フレームワークがある         │
│    [ ] Claudeが知らないドメイン固有手順が含まれている                   │
│    [ ] 価値のある手順と汎用手順を区別                                   │
│                                                                         │
│  アンチパターン:                                                        │
│    [ ] 明示的なNEVERリストがある                                        │
│    [ ] アンチパターンは具体的で曖昧ではない                             │
│    [ ] 「なぜ」が含まれている(非自明な理由)                              │
│                                                                         │
│  仕様(説明は重要!):                                                     │
│    [ ] 有効なYAMLフロントマター                                         │
│    [ ] name: 小文字、≤64文字                                           │
│    [ ] description: それは何をしますか? に答える                        │
│    [ ] description: いつ使うべきか? に答える                            │
│    [ ] description: トリガーキーワードを含む                            │
│    [ ] description: エージェントがいつ使うか知るのに十分に具体的        │
│                                                                         │
│  構造:                                                                  │
│    [ ] SKILL.md < 500行(理想は<300)                                    │
│    [ ] 重いコンテンツはreferences/内                                    │
│    [ ] 読み込みトリガーがワークフロー内に組み込まれている                │
│    [ ] 過度なロードを防ぐための「ロードしないでください」               │
│                                                                         │
│  自由度:                                                               │
│    [ ] クリエイティブなタスク → 高い自由度(原則)                        │
│    [ ] 脆弱な操作 → 低い自由度(正確なスクリプト)                        │
│                                                                         │
│  実用性:                                                               │
│    [ ] マルチパスシナリオのための意思決定木                              │
│    [ ] 機能するコード例                                                 │
│    [ ] エラーハンドリングとフォールバック                                │
│    [ ] カバーされるエッジケース                                         │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

---

メタクエスチョン

スキルを評価するときは、常にこの根本的な質問に戻ってください:

「このドメインのエキスパートがこのスキルを見て、 「はい、これは数年かかって習得した知識をキャプチャしている」と言うか?」

答えが「はい」なら → スキルは本当の価値を持っています。 答えが「いいえ」なら → それはClaudeが既に知っていることを圧縮しています。

最高のスキルは圧縮されたエキスパートブレイン — デザイナーの10年の美的蓄積を43行に圧縮したり、ドキュメント専門家の実務経験を200行の意思決定木に圧縮したりします。

圧縮されるものはClaudeが持たないものである必要があります。そうでなければ、それはゴミ圧縮です。

---

自己評価ノート

このスキル(skill-judge)自身が評価に合格すべき:

• 知識デルタ: Claudeが自分で生成しない具体的な評価基準を提供
• マインドセット: スキル品質についての考え方を形作り、チェックリスト項目だけではない
• アンチパターン: 「評価する際に決してしないこと」セクション付き具体的な禁止事項
• 仕様: 有効なフロントマターと包括的な説明
• プログレッシブディスクロージャー: 自己完結型、外部参考資料は不要
• 自由度: 評価タスクに適切な中程度の自由度
• パターン: 意思決定フレームワーク付きツールパターンに従う
• 実用性: 明確なプロトコル、レポートテンプレート、クイックリファレンス

キャリブレーション演習として、このスキルを自分自身に対して評価してください。