スキルクリエイターは何をしますか？

新しいスキルを作成し、反復的に改善するためのスキルです。

大まかに言えば、スキルを作成するプロセスは次のようになります。

スキルに何をさせたいか、そして大まかにどのようにそれを実行させるかを決定する
スキルのドラフトを書く
いくつかのテストプロンプトを作成し、それらに対してスキルにアクセスできるClaudeを実行する
結果を定性的および定量的に評価するのをユーザーを支援する
- 実行がバックグラウンドで行われている間に、定量的評価がまだない場合は、いくつかドラフトする（既にある場合は、そのまま使用するか、変更が必要だと感じた場合は修正する）。その後、それらをユーザーに説明する（または既に存在する場合は、既存のものを説明する）
- eval-viewer/generate_review.pyスクリプトを使用して、結果をユーザーが確認できるように表示し、定量的メトリクスも確認できるようにする
ユーザーによる結果の評価からのフィードバック（および定量的ベンチマークから明らかになった明らかな欠陥があればそれも）に基づいてスキルを書き直す
満足するまで繰り返す
テストセットを拡張し、より大規模に再試行する

このスキルを使用する際のあなたの仕事は、ユーザーがこのプロセスのどの段階にいるのかを把握し、彼らがこれらのステージを進むのを助けるために介入することです。たとえば、ユーザーが「Xのためのスキルを作りたい」と言っているかもしれません。あなたは、彼らの意図を絞り込み、ドラフトを作成し、テストケースを作成し、評価方法を決定し、すべてのプロンプトを実行し、繰り返すのを支援できます。

一方で、すでにスキルのドラフトがある場合もあります。その場合、評価/反復のループに直接進むことができます。

もちろん、常に柔軟に対応し、ユーザーが「たくさんの評価を実行する必要はないよ、一緒に感覚でやろう」と言った場合には、そのようにすることもできます。

スキルが完成した後（ただし、順序は柔軟です）、スキルのトリガーを最適化するために、別のスクリプトがあるスキル説明改善ツールを実行することもできます。

いいですか？

ユーザーとのコミュニケーション

スキルクリエイターは、コーディングの専門用語にさまざまなレベルの精通度を持つ人々に使用される可能性があります。もし聞いていないのであれば（最近始まったばかりなので、聞いているはずがありませんが）、今、Claudeのパワーが、配管工にターミナルを開かせ、親や祖父母に「npmのインストール方法」をGoogle検索させるというトレンドがあります。一方で、ユーザーの大部分はおそらくかなりコンピューターに精通しています。

したがって、文脈の手がかりに注意を払い、コミュニケーションの表現方法を理解してください！デフォルトのケースでは、いくつかのアイデアを示します。

「評価」と「ベンチマーク」はグレーゾーンですが、OKです
「JSON」と「アサーション」については、ユーザーがそれらを理解していることを示す確かな手がかりがない限り、説明なしで使用しないでください

疑問がある場合は、用語を簡単に説明しても構いません。また、ユーザーが理解できるかどうかわからない場合は、短い定義で用語を明確にしてください。

スキルの作成

意図の捕捉

まず、ユーザーの意図を理解することから始めます。現在の会話には、ユーザーがキャプチャしたいワークフローがすでに含まれている場合があります（例：「これをスキルにしてください」と言う）。その場合は、会話履歴から回答を抽出します。使用されたツール、一連の手順、ユーザーが行った修正、観察された入出力形式などです。ユーザーはギャップを埋める必要がある場合があり、次のステップに進む前に確認する必要があります。

このスキルは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:**
入力: Added user authentication with JWT tokens
出力: feat(auth): implement JWT-based authentication

記述スタイル

強引な「しなければならない」ではなく、なぜ重要なのかをモデルに説明するようにしてください。心の理論を使用し、スキルを特定の例に過度に限定せず、一般的なものにするようにしてください。まずドラフトを作成し、新鮮な目で見直して改善します。

テストケース

スキルのドラフトを作成した後、2〜3の現実的なテストプロンプトを考案します。実際のユーザーが実際に言うようなものです。それらをユーザーと共有します。[この正確な言語を使用する必要はありません]「試してみたいテストケースをいくつかご紹介します。これらは適切に見えますか、それともさらに追加しますか？」その後、実行します。

テストケースを evals/evals.json に保存します。アサーションはまだ記述しないでください。プロンプトのみです。次のステップで、実行中にアサーションを作成します。

{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "User's task prompt",
      "expected_output": "Description of expected result",
      "files": []
    }
  ]
}

完全なスキーマ（後で追加する assertions フィールドを含む）については、references/schemas.md を参照してください。

テストケースの実行と評価

このセクションは連続したシーケンスです。途中で止めないでください。/skill-test やその他のテストスキルは使用しないでください。

結果を <skill-name>-workspace/ に、スキルディレクトリの兄弟として配置します。ワークスペース内では、反復ごとに結果を整理します (iteration-1/、iteration-2/ など)。さらに、各テストケースにディレクトリを作成します (eval-0/、eval-1/ など)。これらを事前にすべて作成するのではなく、進めながらディレクトリを作成してください。

ステップ1: すべての実行を同じターンで開始する (スキルありとベースライン)

各テストケースについて、同じターンで2つのサブエージェントを開始します。1つはスキルあり、もう1つはスキルなしです。これが重要です。最初にスキルありの実行を開始し、後でベースラインに戻ってくるのは避けてください。すべてを同時に開始して、ほぼ同じ時間に終了するようにします。

スキルあり実行:

このタスクを実行:
- スキルパス: <path-to-skill>
- タスク: <eval prompt>
- 入力ファイル: <eval files if any, or "none">
- 出力を保存: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- 保存する出力: <what the user cares about — e.g., "the .docx file", "the final CSV">

ベースライン実行 (同じプロンプトですが、ベースラインはコンテキストに依存します):

新しいスキルの作成: スキルなし。同じプロンプト、スキルパスなし、without_skill/outputs/ に保存。
既存のスキルの改善: 古いバージョン。編集する前に、スキルをスナップショットします (cp -r <skill-path> <workspace>/skill-snapshot/)。次に、ベースラインサブエージェントをスナップショットに向けます。old_skill/outputs/ に保存します。

各テストケースの eval_metadata.json を記述します（アサーションはとりあえず空でも構いません）。各評価に、テスト内容に基づいて説明的な名前を付けます。「eval-0」などではなく。この名前をディレクトリにも使用します。この反復で新しいevalプロンプトまたは変更されたevalプロンプトを使用する場合は、新しい各evalディレクトリに対してこれらのファイルを作成します。以前の反復から引き継がれるとは想定しないでください。

{
  "eval_id": 0,
  "eval_name": "descriptive-name-here",
  "prompt": "The user's task 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>
```
これにより、各設定の合格率、時間、トークンを含む benchmark.json と benchmark.md が生成され、平均 ± 標準偏差と差分が表示されます。benchmark.jsonを手動で生成する場合は、ビューアが期待する正確なスキーマについて references/schemas.md を参照してください。各スキルありのバージョンを、対応するベースラインの前に配置します。
アナリストパスを実行する — ベンチマークデータを読み取り、集計統計が隠す可能性のあるパターンを表面化します。agents/analyzer.md（「ベンチマーク結果の分析」セクション）で何を探すべきかを確認します。スキルに関係なく常に合格するアサーション（非識別）、分散の大きい評価（おそらく不安定）、時間とトークンのトレードオフなどです。
ビューアを起動する — 定性的な出力と定量的なデータの両方を表示します:
```
nohup python <skill-creator-path>/eval-viewer/generate_review.py
```

…

[truncated for translation]

スキルクリエイター