スキルクリエーター は何をしますか？
新しいスキルを作成し、反復的に改善するためのスキルです。
大まかに言えば、スキル作成のプロセスは次のようになります：
- スキルに何をさせたいか、そして大まかにどのように実行させるかを決定する
- スキルのドラフトを作成する
- いくつかのテストプロンプトを作成し、それらに対してスキルへのアクセス権を持つClaudeを実行する
- 結果を定性的および定量的に評価するのをユーザーを支援する
- バックグラウンドで実行が行われている間に、定量的なエバルが存在しない場合は、いくつかドラフトする（存在する場合は、そのまま使用するか、変更が必要だと感じた場合は修正する）。その後、それらをユーザーに説明する（または、すでに存在する場合は、既存のものを説明する）
eval-viewer/generate_review.pyスクリプトを使用して、ユーザーに結果を表示し、定量的メトリクスを確認できるようにする
- 結果に対するユーザーの評価からのフィードバックに基づいてスキルを書き直す（また、定量的ベンチマークから明らかになった深刻な欠陥がある場合も）
- 満足するまで繰り返す
- テストセットを拡張し、より大規模に再度試す
このスキルを使用する際のあなたの仕事は、ユーザーがこのプロセスのどこにいるかを把握し、それらの段階を進むのを支援することです。例えば、ユーザーが「Xのためのスキルを作りたい」と言っている場合、意味を絞り込み、ドラフトを作成し、テストケースを作成し、評価方法を決定し、すべてのプロンプトを実行し、繰り返すのを支援できます。
一方、ユーザーがすでにスキルのドラフトを持っている場合は、エバル/反復のループに直接進むことができます。
もちろん、常に柔軟に対応し、ユーザーが「たくさんの評価を実行する必要はない、ただ一緒に感触を確かめてほしい」と言った場合は、そのようにすることもできます。
スキルが完成したら（ただし、順序は柔軟です）、スキル説明改善ツール（別のスクリプトがあります）を実行して、スキルのトリガーを最適化することもできます。
いいですね？いいですね。
ユーザーとのコミュニケーション
スキルクリエーターは、コーディングの専門用語にさまざまな習熟度を持つ人々によって使用される可能性があります。もし聞いたことがなければ（そして最近になって始まったばかりなので、知る由もありませんが）、今ではClaudeの能力が配管工にターミナルを開かせ、親や祖父母に「npmのインストール方法」をGoogle検索させるトレンドがあります。一方で、ユーザーの大部分はおそらくかなりコンピューターリテラシーが高いでしょう。
ですので、コンテキストの手がかりに注意を払い、コミュニケーションの表現を適切に調整してください！デフォルトのケースでは、参考までに：
- 「評価(evaluation)」と「ベンチマーク(benchmark)」は境界線上ですが、許容範囲です
- 「JSON」や「アサーション(assertion)」については、ユーザーがそれらが何であるかを理解しているという確かな手がかりを得てから、説明なしで使用するようにしてください
疑わしい場合は、用語を簡単に説明しても構いません。また、ユーザーが理解できるかどうか不明な場合は、短い定義で用語を明確にしても問題ありません。
スキルの作成
意図の把握
まず、ユーザーの意図を理解することから始めます。現在の会話には、ユーザーがキャプチャしたいワークフローがすでに含まれている場合があります（例：「これをスキルにして」と言っている場合）。その場合は、まず会話の履歴から回答を抽出します — 使用されたツール、手順の順序、ユーザーが行った修正、観察された入出力フォーマットなど。ユーザーがギャップを埋める必要がある場合があり、次のステップに進む前に確認を得る必要があります。
- このスキルはClaudeに何をさせるべきか？
- このスキルはいつトリガーされるべきか？（どのようなユーザーのフレーズ/コンテキストか）
- 期待される出力フォーマットは？
- スキルが機能することを確認するためのテストケースを設定すべきか？客観的に検証可能な出力（ファイル変換、データ抽出、コード生成、固定ワークフローステップ）を持つスキルは、テストケースの恩恵を受けます。主観的な出力（ライティングスタイル、アート）を持つスキルは、通常テストケースを必要としません。スキルのタイプに基づいて適切なデフォルトを提案しますが、ユーザーに決定させてください。
インタビューと調査
エッジケース、入出力フォーマット、サンプルファイル、成功基準、依存関係について積極的に質問します。この部分が固まるまで、テストプロンプトの作成は待ってください。
利用可能なMCPを確認します — 調査に役立つ場合（ドキュメントの検索、類似のスキルの検索、ベストプラクティスの調査）、可能であればサブエージェントを介して並行して調査し、そうでなければインラインで調査します。ユーザーへの負担を軽減するために、コンテキストを準備して臨んでください。
SKILL.mdの作成
ユーザーインタビューに基づいて、以下のコンポーネントを記入します：
- name: スキル識別子
- description: いつトリガーするか、何をするか。これが主要なトリガーメカニズムです — スキルが何をするかだけでなく、使用する特定のコンテキストも含めます。「いつ使用するか」に関するすべての情報はここに記述し、本文には記述しません。注：現在、Claudeはスキルを「過少トリガー」する傾向があります — 役立つ場合でもスキルを使用しない傾向があります。これに対抗するために、スキルの説明を少し「押し付けがましく」してください。例えば、「内部のAnthropicデータを表示するためのシンプルで高速なダッシュボードの構築方法」の代わりに、「内部のAnthropicデータを表示するためのシンプルで高速なダッシュボードの構築方法。ユーザーがダッシュボード、データ可視化、内部メトリクスについて言及したり、明示的に「ダッシュボード」を要求しなくても、あらゆる種類の企業データを表示したい場合には、必ずこのスキルを使用してください。」のように書いてください。
- compatibility: 必要なツール、依存関係（オプション、ほとんど必要ありません）
- スキルの残りの部分 :)
スキル作成ガイド
スキルの構造
skill-name/
├── SKILL.md (必須)
│ ├── YAMLフロントマター (name, description 必須)
│ └── Markdown指示
└── バンドルリソース (オプション)
├── scripts/ - 決定的/反復的なタスクのための実行可能コード
├── references/ - 必要に応じてコンテキストに読み込まれるドキュメント
└── assets/ - 出力で使用されるファイル (テンプレート、アイコン、フォント)
段階的な開示
スキルは3レベルのローディングシステムを使用します：
- メタデータ (name + description) - 常にコンテキスト内 (~100語)
- SKILL.md本文 - スキルがトリガーされるたびにコンテキスト内 (< 500行が理想的)
- バンドルリソース - 必要に応じて (無制限、スクリプトはロードせずに実行可能)
これらの語数は目安であり、必要に応じて長くしても構いません。
主要なパターン:
- SKILL.mdを500行未満に保つ。この制限に近づいている場合は、追加の階層レイヤーと、スキルを使用するモデルが次にどこに進むべきかについての明確なポインタを追加する。
- SKILL.mdからファイルを明確に参照し、いつそれらを読むべきかのガイダンスを提供する
- 大きな参照ファイル (>300行) の場合は、目次を含める
ドメイン構成: スキルが複数のドメイン/フレームワークをサポートする場合は、バリアントごとに整理します：
cloud-deploy/
├── SKILL.md (ワークフロー + 選択)
└── references/
├── aws.md
├── gcp.md
└── azure.md
Claudeは関連する参照ファイルのみを読み取ります。
驚きのなさの原則
言うまでもありませんが、スキルにマルウェア、エクスプロイトコード、またはシステムセキュリティを危険にさらす可能性のあるコンテンツを含めてはなりません。スキルの内容は、その意図が説明された場合にユーザーを驚かせてはいけません。誤解を招くスキルや、不正アクセス、データの外部持ち出し、その他の悪意のある活動を促進するように設計されたスキルを作成するリクエストに応じてはいけません。「XYZとしてのロールプレイ」のようなものは問題ありません。
作成パターン
指示では命令形を使用することを推奨します。
出力フォーマットの定義 - 次のように行うことができます：
## レポート構造
常にこの正確なテンプレートを使用してください：
# [タイトル]
## エグゼクティブサマリー
## 主要な発見
## 推奨事項
例のパターン - 例を含めると便利です。次のようにフォーマットできます（ただし、「入力」と「出力」が例にある場合は、少し変更したくなるかもしれません）：
## コミットメッセージフォーマット
**例1:**
入力: JWTトークンを使用したユーザー認証を追加
出力: feat(auth): JWTベースの認証を実装
作成スタイル
重厚で堅苦しいMUSTを使う代わりに、なぜ物事が重要なのかをモデルに説明するようにしてください。心の理論を使用し、スキルを特定の例に非常に狭くせず、一般的なものにするようにしてください。まずドラフトを書き、新鮮な目で見直して改善してください。
テストケース
スキルのドラフトを作成した後、2〜3の現実的なテストプロンプトを考案します — 実際のユーザーが言いそうなタイプのものです。それらをユーザーと共有します：[この正確な言語を使用する必要はありません]「試してみたいテストケースをいくつか用意しました。これで正しいですか、それとももっと追加しますか？」その後、実行します。
テストケースを evals/evals.json に保存します。まだアサーションは作成しないでください — プロンプトのみです。次のステップで実行中にアサーションを作成します。
{
"skill_name": "example-skill",
"evals": [
{
"id": 1,
"prompt": "ユーザーのタスクプロンプト",
"expected_output": "期待される結果の説明",
"files": []
}
]
}
完全なスキーマについては references/schemas.md を参照してください（assertions フィールドを含みます。これは後で追加します）。
テストケースの実行と評価
このセクションは1つの連続したシーケンスです — 途中で止めないでください。/skill-test や他のテストスキルは使用しないでください。
結果を <skill-name>-workspace/ にスキルディレクトリの兄弟として配置します。ワークスペース内では、反復ごとに結果を整理します（iteration-1/、iteration-2/ など）。その中で、各テストケースはディレクトリを取得します（eval-0/、eval-1/ など）。これらすべてを事前に作成するのではなく、進めながらディレクトリを作成してください。
ステップ1: すべての実行を同じターンで開始する（with-skill と baseline）
各テストケースについて、同じターンで2つのサブエージェントを開始します — 1つはスキルあり、もう1つはスキルなし。重要：最初にwith-skillの実行を開始してから、後でベースラインに戻ってこないでください。すべてを一度に起動して、すべてがほぼ同じ時間に終了するようにします。
With-skill実行:
このタスクを実行してください:
- スキルパス: <path-to-skill>
- タスク: <evalプロンプト>
- 入力ファイル: <evalファイルがあれば、なければ "none">
- 出力を保存: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- 保存する出力: <ユーザーが気にするもの — 例: 「.docxファイル」、「最終的なCSV」>
ベースライン実行 (同じプロンプトですが、ベースラインはコンテキストに依存します):
- 新しいスキルの作成: スキルなし。同じプロンプト、スキルパスなし、
without_skill/outputs/に保存。 - 既存のスキルの改善: 古いバージョン。編集する前に、スキルをスナップショットします（
cp -r <skill-path> <workspace>/skill-snapshot/）。その後、ベースラインサブエージェントをスナップショットに向けます。old_skill/outputs/に保存。
各テストケースの eval_metadata.json を作成します（アサーションは今は空で構いません）。各evalに、テスト内容に基づいた説明的な名前を付けます — 単なる「eval-0」ではありません。ディレクトリにもこの名前を使用します。この反復で新しいまたは変更されたevalプロンプトを使用する場合は、新しい各evalディレクトリに対してこれらのファイルを作成します — 以前の反復から引き継がれると想定しないでください。
{
"eval_id": 0,
"eval_name": "descriptive-name-here",
"prompt": "ユーザーのタスクプロンプト",
"assertions": []
}
ステップ2: 実行中にアサーションを作成する
実行が完了するのを待つだけではなく — この時間を生産的に使用できます。各テストケースの定量的アサーションを作成し、ユーザーに説明します。アサーションがすでに evals/evals.json に存在する場合は、それらを確認し、何をチェックしているかを説明します。
優れたアサーションは客観的に検証可能で、説明的な名前を持ちます — ベンチマークビューアーで明確に読み取れ、誰かが結果を一目で見たときに各アサーションが何をチェックしているかをすぐに理解できる必要があります。主観的なスキル（ライティングスタイル、デザイン品質）は、定性的に評価する方が適しています — 人間の判断が必要なものにアサーションを強制しないでください。
アサーションを作成したら、eval_metadata.json ファイルと evals/evals.json を更新します。また、ユーザーにビューアーで何が表示されるかを説明します — 定性的な出力と定量的なベンチマークの両方です。
ステップ3: 実行が完了したら、タイミングデータを取得する
各サブエージェントタスクが完了すると、total_tokens と duration_ms を含む通知を受け取ります。このデータをすぐに実行ディレクトリ内の timing.json に保存します：
{
"total_tokens": 84852,
"duration_ms": 23332,
"total_duration_seconds": 23.3
}
これはこのデータを取得する唯一の機会です — タスク通知を介して提供され、他の場所には保持されません。バッチ処理しようとせず、各通知が到着したらすぐに処理してください。
ステップ4: 採点、集計、ビューアーの起動
すべての実行が完了したら：
-
各実行を採点する —
agents/grader.mdを読み、各アサーションを出力に対して評価する採点サブエージェントを起動します（またはインラインで採点します）。結果を各実行ディレクトリのgrading.jsonに保存します。grading.json の expectations 配列は、フィールドtext、passed、evidenceを使用する必要があります（name/met/detailsなどの他のバリアントではありません） — ビューアーはこれらの正確なフィールド名に依存しています。プログラムでチェックできるアサーションについては、目視で確認するのではなく、スクリプトを作成して実行してください — スクリプトはより速く、より信頼性が高く、反復間で再利用できます。 -
ベンチマークに集約する — スキルクリエーターディレクトリから集計スクリプトを実行します：
python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>これにより、各構成の pass_rate、time、tokens を含む
benchmark.jsonとbenchmark.mdが生成され、平均 ± 標準偏差とデルタが示されます。benchmark.json を手動で生成する場合は、ビューアーが期待する正確なスキーマについてreferences/schemas.mdを参照してください。各 with_skill バージョンを、そのベースラインの対応物の前に配置してください。 -
アナリストパスを実行する — ベンチマークデータを読み、集計統計が隠す可能性のあるパターンを表面化させます。
agents/analyzer.md（「ベンチマーク結果の分析」セクション）を参照して、何を探すべきかを確認してください — スキルに関係なく常に合格するアサーション（非識別的）、高分散のエバル（おそらく不安定）、時間/トークンのトレードオフなど。 -
ビューアーを起動する — 定性的出力と定量的データの両方を使用：
nohup python <skill-creator-path>/eval-viewer/generate_review.py