make-skill

スキルの作成または修正

エージェントがソースだけから確実に推測できない知識を補う、簡潔で安定したタスクガイダンスと、そのガイダンスによって動作が変わることを証明する評価を対で作成します。

適切なプリミティブを選ぶ

• オンデマンドで読み込む、タスク固有のワークフローや知識体系にはスキルを使用します。
• パスごとに適用する背景ガイダンスにはファイル指示を使用します。
• コンテキストの分離や異なるツール制限が必要な場合は、カスタムエージェントを使用します。
• 重複するスキルを新規作成するより、既存のスキルを優先します。

ワークフロー

1. 関連する実装、テスト、リポジトリの指示、および近接するカスタマイズを読みます。
2. 繰り返し発生するミスや、自明ではない不変条件を特定します。ソースの一覧、行数、コードから簡単に再発見できる事実をスキルの内容にしないでください。
3. .agents/skills/<name>/SKILL.md を作成します。フロントマターの name はディレクトリ名と完全に一致させ、説明にはスキルの機能と、どのような自然なユーザー要求で有効化すべきかを記載します。
4. 背景となるドメインガイダンスには user-invocable: false を設定します。ユーザーが意図的に求める成果に、ユーザーが呼び出せるワークフローの焦点を合わせます。
5. 観測可能な検証を伴う、実行可能なガイダンスを記述します。エッジケースが重要な理由を説明し、リポジトリの指示にすでにある一般的なエンジニアリング助言は避けます。
6. eng/harness-evaluation/skills/<name>/eval.yaml を作成し、eng/harness-evaluation/README.md に従います。
7. カスタマイズをリントし、受け入れる前にコントロールとトリートメントの両方の成果物を確認します。

対比較評価

• 評価ルートの agent_environment.skills には対象のスキルだけを含めます。刺激入力は各刺激の agent_environment.files 配下に置きます。
• ランナーはコントロール用にルートのスキルを削除し、トリートメントでスキルが有効化されたことを別途検証します。skill-invocation グレーダーを追加せず、共通プロンプトでエージェントにスキルの呼び出しを指示しないでください。
• プロンプトには、フィクスチャ、提案するコード、固定 ID、出力パスを指定してもかまいません。ただし、期待される診断、担当する仕組み、回帰テストの設計を明かしてはいけません。
• 差分やコミット参照ではなく、自己完結したソースのスナップショットを用意します。フィクスチャのコンテキストは、リポジトリのリビジョンを取得しなくても成立する必要があります。
• 観測可能な成果物には決定論的グレーダーを、動作には範囲を絞った意味的ルーブリックを使用し、token-budget グレーダーも含めます。ターン数、トークン数、実行時間に上限を設け、コミット済みの採点しきい値を設定します。
• タスクでは、そのスキルに特有のガイダンスを検証します。コントロールが常にトリートメントと同等の結果になる場合、そのスキルまたは評価は十分に有用ではありません。

検証

• フロントマターが解析でき、名前がディレクトリ名と一致していること。
• スキルが簡潔で安定しており、ルートまたはスコープ付きの指示と重複していないこと。
• ファイル参照が相対パスで、参照先が存在すること。
• 検証手順が観測可能で、タスクに固有であること。
• 対比較評価が対象のスキルだけを対象とし、上限のある評価が完全に定義され、解法を誘導しないプロンプトを使用していること。
• npm run lint とハーネスのインベントリテストが通ること。

よくある落とし穴

落とし穴	修正方法
実装の一覧をそのままスキルにコピーする	自明ではない不変条件と振り分けの判断だけを残す
正確な行数や変動しやすい指標を含める	削除し、安定したシンボルや動作を参照する
一般的なテストフォルダーの説明を含める	特有のテスト形式を説明するか、省略する
評価プロンプトで見つけるべき内容を明かす	期待される事実は非公開のルーブリックに移す
評価ルートにリポジトリのフィクスチャを置く	ルートには対象のスキルだけを残し、フィクスチャは刺激ごとに用意する
プロンプトでスキルの呼び出しを指示する	トリートメント専用ランナーのゲートで有効化を強制する
初期のひな形作成で複数モデルによるレビューを始める	まず依頼された成果物を作成してリントし、コストの高い動作検証は別途実行する