スキルクリエーター

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

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

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

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

このスキルを使用する際のあなたの役割は、ユーザーがこのプロセスのどこにいるのかを把握し、その段階を進むのを支援することです。例えば、ユーザーが「Xのためのスキルを作りたい」と言った場合、その意味を絞り込み、ドラフトを作成し、テストケースを作成し、評価方法を決め、すべてのプロンプトを実行し、繰り返すのを支援します。

一方、ユーザーがすでにスキルのドラフトを持っている場合は、評価/反復のループに直接進むことができます。

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

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

いいですね？

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

スキルクリエーターは、コーディング用語に様々なレベルの習熟度を持つ人々に使用される可能性があります。最近（と言っても最近始まったばかりですが）、Claudeの力に触発されて、配管工がターミナルを開き、祖父母が「npmのインストール方法」をGoogleで検索するというトレンドがあります。一方、大多数のユーザーはおそらくコンピューターにかなり精通しています。

したがって、コンテキストの手がかりに注意を払い、コミュニケーションの表現方法を理解してください！デフォルトの場合、参考までに：

• 「評価（evaluation）」と「ベンチマーク（benchmark）」は微妙なラインですが、問題ありません
• 「JSON」や「アサーション（assertion）」については、説明なしで使用する前に、ユーザーがそれらを理解していることを示す明確な手がかりが必要です

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

---

スキルの作成

意図のキャプチャ

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

1. このスキルはClaudeに何をさせるべきですか？
2. このスキルはいつトリガーされるべきですか？（どのようなユーザーのフレーズ/コンテキストで）
3. 期待される出力形式は何ですか？
4. スキルが動作することを確認するためのテストケースを設定すべきですか？客観的に検証可能な出力（ファイル変換、データ抽出、コード生成、固定ワークフローステップ）を持つスキルは、テストケースの恩恵を受けます。主観的な出力（文体、アート）を持つスキルは、通常テストケースを必要としません。スキルのタイプに基づいて適切なデフォルトを提案しますが、ユーザーに決定させてください。

インタビューと調査

エッジケース、入出力形式、サンプルファイル、成功基準、依存関係について積極的に質問します。この部分が固まるまで、テストプロンプトを作成するのは待ってください。

利用可能なMCPを確認します — 調査に役立つ場合（ドキュメントの検索、類似スキルの発見、ベストプラクティスの調査）、サブエージェントが利用可能であれば並行して調査し、そうでなければインラインで調査します。ユーザーの負担を減らすために、コンテキストを準備して臨んでください。

SKILL.md を書く

ユーザーインタビューに基づいて、以下のコンポーネントを埋めます：

• name: スキル識別子
• description: いつトリガーされるか、何をするか。これが主要なトリガー機構です — スキルが何をするかと、いつ使用すべきかの特定のコンテキストの両方を含めます。「いつ使用するか」の情報はすべてここに記述し、本文には記述しません。注意：現在、Claudeはスキルを「過少トリガー」する傾向があります — 役立つ場面でも使用しない傾向があります。これに対抗するために、スキルの説明を少し「押し付けがましく」してください。例えば、「内部のAnthropicデータを表示するためのシンプルで高速なダッシュボードの構築方法」の代わりに、「内部のAnthropicデータを表示するためのシンプルで高速なダッシュボードの構築方法。ユーザーがダッシュボード、データ可視化、内部メトリクスについて言及したり、明示的に「ダッシュボード」を要求しなくても、あらゆる種類の会社データを表示したい場合には、必ずこのスキルを使用すること。」と書いてください。
• compatibility: 必要なツール、依存関係（オプション、ほとんど必要ありません）
• **残りのスキル :) **

スキル作成ガイド

スキルの構造

skill-name/
├── SKILL.md (必須)
│   ├── YAML frontmatter (name, description 必須)
│   └── Markdown 指示
└── Bundled Resources (オプション)
    ├── scripts/    - 決定論的/反復的なタスクのための実行可能コード
    ├── references/ - 必要に応じてコンテキストに読み込まれるドキュメント
    └── assets/     - 出力で使用されるファイル（テンプレート、アイコン、フォント）

段階的な開示

スキルは3レベルの読み込みシステムを使用します：

1. メタデータ (name + description) - 常にコンテキスト内（約100ワード）
2. SKILL.md 本文 - スキルがトリガーされるたびにコンテキスト内（理想は500行未満）
3. バンドルリソース - 必要に応じて（無制限、スクリプトは読み込まずに実行可能）

これらのワードカウントは概算であり、必要に応じて長くしても構いません。

重要なパターン:

• SKILL.mdを500行未満に保つ。この制限に近づいている場合は、追加の階層レイヤーと、スキルを使用するモデルが次にどこに進むべきかについての明確なポインタを追加する。
• SKILL.mdからファイルを明確に参照し、いつ読むべきかのガイダンスを提供する
• 大きな参照ファイル（300行超）の場合は、目次を含める

ドメイン構成: スキルが複数のドメイン/フレームワークをサポートする場合、バリアントごとに構成する：

cloud-deploy/
├── SKILL.md (ワークフロー + 選択)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

Claudeは関連する参照ファイルのみを読み取ります。

驚きのなさの原則

言うまでもありませんが、スキルにはマルウェア、エクスプロイトコード、またはシステムセキュリティを危険にさらす可能性のあるコンテンツを含めてはなりません。スキルの内容は、その意図を説明された場合にユーザーを驚かせるものであってはなりません。誤解を招くスキルや、不正アクセス、データ流出、その他の悪意のある活動を容易にするために設計されたスキルを作成するリクエストに従ってはいけません。「XYZのロールプレイ」のようなものは問題ありません。

記述パターン

指示では命令形を使用することを推奨します。

出力形式の定義 - 次のように行うことができます：

## レポート構造
常にこの正確なテンプレートを使用する：
# [タイトル]
## エグゼクティブサマリー
## 主要な発見
## 推奨事項

例のパターン - 例を含めると便利です。次のようにフォーマットできます（ただし、「入力」と「出力」が例にある場合は、少し変更したほうがよいかもしれません）：

## コミットメッセージの形式
**例1:**
入力：JWTトークンを使用したユーザー認証を追加
出力：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: すべての実行（スキルあり AND ベースライン）を同じターンで起動する

各テストケースについて、同じターンで2つのサブエージェントを起動します — 1つはスキルあり、もう1つはスキルなし。これは重要です：スキルありの実行を先に起動し、後でベースラインに戻ってくるのは避けてください。すべてを一度に起動し、大体同じ時間に終了するようにします。

スキルありの実行:

このタスクを実行してください：
- スキルパス: <path-to-skill>
- タスク: <eval プロンプト>
- 入力ファイル: <eval ファイルがあれば、なければ「なし」>
- 出力を保存: <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ディレクトリに対してこれらのファイルを作成します — 以前のイテレーションから引き継がれると想定しないでください。

{
  "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: 採点、集計、ビューアーの起動

すべての実行が完了したら：

1. 各実行を採点する — 採点者サブエージェントを起動するか（インラインで採点）、agents/grader.md を読み取り、各アサーションを出力に対して評価します。結果を各実行ディレクトリの grading.json に保存します。grading.json の expectations 配列は、フィールド text、passed、evidence を使用する必要があります（name/met/details やその他のバリアントではありません） — ビューアーはこれらの正確なフィールド名に依存しています。プログラムでチェックできるアサーションについては、目視で確認するのではなく、スクリプトを作成して実行してください — スクリプトはより高速で信頼性が高く、イテレーション間で再利用できます。

2. ベンチマークに集約する — スキルクリエーターディレクトリから集約スクリプトを実行します：

   python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
   

   これにより、各構成のpass_rate、時間、トークンを含む benchmark.json と benchmark.md が生成され、平均 ± 標準偏差とデルタが表示されます。benchmark.json を手動で生成する場合は、references/schemas.md でビューアーが期待する正確なスキーマを参照してください。各スキルありバージョンを、そのベースラインの前に配置します。

3. アナリストパスを実行する — ベンチマークデータを読み取り、集計統計が隠している可能性のあるパターンを表面化します。agents/analyzer.md（「ベンチマーク結果の分析」セクション）で何を探すべきか参照してください — スキルに関係なく常にパスするアサーション（非識別）、高分散の評価（おそらく不安定）、時間/トークンのトレードオフなど。

4. ビューアーを起動する — 定性的出力と定量的データの両方を表示します：

   nohup python <skill-creator-path>/eval-viewer/generate_review.py
   

…

[翻訳のため一部省略]