skill-creator

スキル作成ツール

新しいスキルを作成し、繰り返し改善するためのスキルです。

大まかなスキル作成の流れは次のとおりです。

• スキルで何を実現し、どのような方法で実現するかを大まかに決める
• スキルの草案（SKILL.md）を書く
• 現実的なテスト用プロンプトをいくつか使ってスキルを試す
• 定性的な観点（出力は適切に見えるか）と、可能であれば簡単に検証できるアサーションの両方で結果を評価する
• 気づいたことをもとにスキルを改善する
• 満足できるまで繰り返す
• 正確に呼び出されるよう、説明を最適化する

このスキルを使うときのあなたの役割は、ユーザーがこのプロセスのどの段階にいるかを把握し、その段階を進められるよう支援することです。ユーザーが「X 用のスキルを作りたい」と言った場合は、意図を絞り込み、草案を作成し、現実的なプロンプトをいくつか試し、反復して改善します。すでに草案がある場合は、すぐにテストと改善に取りかかります。

ユーザーが「正式な評価はなしで、気楽に一緒に考えて」と言った場合は、そのとおりにします。

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

スキル作成ツールは、コーディング用語への習熟度がさまざまな人に使われる可能性があります。次の文脈上の手がかりに注意してください。

• 「評価」／「ベンチマーク」— おおむね問題ありません
• 「JSON」／「アサーション」— ユーザーに知識があると分かる場合を除き、説明してください

用語の意味が不明な場合は、簡単に説明してもかまいません。

意図を把握する

まず、ユーザーが何をしたいのかを理解します。現在の会話に、すでに把握すべきワークフローが含まれていることもあります（例：「これをスキルにして」）。その場合は、まず会話履歴から、使用したツール、手順、行われた修正、確認された入出力形式を抽出します。不足している情報は、ユーザーに補足してもらい、確認してください。

次の点を尋ねます。

1. このスキルでモデルに何をできるようにしますか？
2. どのようなときにスキルを呼び出すべきですか？（ユーザーの表現や状況）
3. 想定する出力形式は何ですか？
4. スキルが正しく機能するか確認するためのテストケースを用意しますか？ファイル変換、データ抽出、コード生成、定型の手順など、客観的に検証可能な出力を生成するスキルでは、テストケースが役立ちます。文章のスタイルやアートなど、主観的な出力を生成するスキルでは、必要ないこともよくあります。適切な初期案を提案しつつ、最終的にはユーザーに判断してもらってください。

ヒアリングと調査

エッジケース、入出力形式、サンプルファイル、成功基準、依存関係について、積極的に尋ねてください。これらが明確になるまでは、テスト用プロンプトの作成を待ちます。

プラットフォームが並行タスクに対応している場合は、並行して調査します（ドキュメントを検索する、類似のスキルを探す、ベストプラクティスを確認するなど）。

SKILL.md の作成

ヒアリングの内容をもとに、次の項目を設定します。

• name — スキルの識別子です（ディレクトリ名と一致させる必要があり、小文字の英数字と単一のハイフンのみを使用します。正規表現は ^[a-z0-9]+(-[a-z0-9]+)*$ です）。
• description — スキルを呼び出す条件と、スキルが行うことを記述します。これは、スキルを呼び出すための主要な仕組みです。スキルの機能と、使用する具体的な状況の両方を含めてください。「いつ使うか」に関する情報はすべてここに記載し、本文には含めません。スキルは呼び出されにくくなる傾向があるため、説明にはやや積極的な表現を使います。たとえば、単に「高速なダッシュボードを作成する」とするのではなく、「高速なダッシュボードを作成します。ユーザーがダッシュボード、データの可視化、社内指標に言及した場合や、明示的に『ダッシュボード』を求めていなくても、会社のデータを何らかの形で表示したいと考えている場合は、必ずこのスキルを使ってください」とします。
• license（任意）— スキルの配布に適用されるライセンスです。

その後、本文を書きます。

スキルの構成

skill-name/
├── SKILL.md (required)
│   ├── YAML frontmatter (name, description required)
│   └── Markdown instructions
└── Bundled resources (optional)
    ├── scripts/    — Executable code for deterministic / repetitive tasks
    ├── references/ — Docs loaded into context as needed
    └── assets/     — Files used in output (templates, icons, fonts)

段階的な開示

スキルでは、3 段階の読み込みシステムを使用します。

1. メタデータ（名前＋説明）— 常にコンテキストに含まれます（約 100 語）。
2. SKILL.md の本文 — スキルが呼び出されるたびにコンテキストに含まれます。500 行未満を目指してください。
3. バンドルされたリソース — 必要に応じて読み込まれます。サイズに上限はなく、スクリプトは読み込まずに実行できます。

主なパターン：

• SKILL.md は 500 行未満に保ちます。上限に近づいたら、明確な参照先を示す案内を添えて、階層をもう 1 段追加します。
• SKILL.md から参照ファイルへの参照を明確に記載し、いつ読むべきかを案内します。
• 大きな参照ファイル（300 行超）には、目次を含めます。

ドメインの整理： スキルが複数のドメイン／フレームワークに対応する場合は、バリエーションごとに整理します。

cloud-deploy/
├── SKILL.md (workflow + selection)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

モデルは関連する参照ファイルのみを読み込みます。

驚きを避ける原則

スキルに、マルウェア、エクスプロイトコード、またはシステムセキュリティを侵害する可能性のある内容を含めてはいけません。スキルの内容は、その説明からユーザーが想定できる範囲に収める必要があります。誤解を招くスキルや、不正アクセス、データの持ち出し、その他の悪意ある活動を助長する目的のスキルを作成しないでください。ロールプレイ形式のスキルは問題ありません。

執筆スタイル

• 指示には命令形を使います（「X を実行する」「Y を実行する」）。
• 指示の理由を説明します。現在のモデルは賢く、厳格なルールよりも理由を理解したほうが適切に従います。大文字の MUST や NEVER を多用しているなら、それは注意信号です。理由を説明する形に書き換えてください。
• 指示は、特定のテスト例だけに限定せず、汎用的で再利用できるものにします。

出力形式の定義 — 明確なテンプレートを使います。

## Report structure
ALWAYS use this exact template:
# [Title]
## Executive summary
## Key findings
## Recommendations

例のパターン — 小さく具体的な例が役立ちます。

## Commit message format
**Example 1:**
Input: Added user authentication with JWT tokens
Output: feat(auth): implement JWT-based authentication

テストケース

草案を作成したら、現実的なテストプロンプトを 2～3 個考えます。実際のユーザーが使いそうなものにしてください。ユーザーに共有します。「試してみたいテストケースをいくつか用意しました。内容は適切ですか？ 追加したいものはありますか？」

各プロンプトでスキルを試します。最終出力だけでなく、トランスクリプトも読んで、スキルによってモデルが役に立たない手順に労力を費やしていないか確認します。

改善の反復

• フィードバックから一般化します。 スキルはさまざまなプロンプトで何度も使われます。テストケースに過剰適合しないようにします。解決しにくい問題があれば、厳格な MUST を追加するのではなく、別の比喩やパターンを試します。
• プロンプトを簡潔に保ちます。 役に立たない指示は削除します。
• 理由を説明します。 モデルは、機械的に覚えたルールよりも理由に基づいて適切に動作します。
• テストケース間で繰り返されている作業を探します。 複数回の実行で同じヘルパースクリプトがそれぞれ独立して作成された場合は、scripts/ にまとめ、スキルから使用するよう指示する合図です。

スキルを改善したら、テストプロンプトを再実行し、以前の動作を損なうことなく問題が解決したか確認します。

説明の最適化（上級）

description フィールドは、モデルがスキルを呼び出すかどうかを決める主要な仕組みです。最適化するには、次の手順を実行します。

1. 呼び出すべきケースと呼び出すべきでないケースを混ぜた、トリガー評価用クエリを約 20 個作成します。呼び出すべきでないケースには、明らかな否定ではなく、紛らわしい類似ケースを使います。
2. 評価セットをユーザーに確認してもらいます。
3. 説明を反復して改善し、各バージョンを学習用クエリと保留テスト用クエリの両方で検証します。過剰適合を避けるため、学習用セットではなく保留セットで最も良い結果を出す説明を選びます。

メモ

これは anthropics/skills/skills/skill-creator を改変して移植したものです。上流版には、バンドルされたスクリプトと HTML 評価ビューア（scripts/aggregate_benchmark.py、eval-viewer/generate_review.py など）が含まれていますが、ここには含まれていません。レビュー済みの上流スナップショットは UPSTREAMS.json で固定されています。