スキルアクティベーションチェック
スキルは、モデルが適切なタイミングでそれを利用して初めてその価値を発揮します。
その判断はほぼ完全にスキルのフロントマター description から行われます。つまり、「自分のスキルはトリガーされるか?」は測定可能な質問であり、これがその測定方法です。つまり、ラベル付きのユーザーリクエストセットを構築し、各リクエストに対して実際のエージェントを実行し、スキルが実際に使用されたかをスコアリングします。
ユーザーのリクエストは次の通りです: $ARGUMENTS
ステップ1 — 対象スキルを特定する
$ARGUMENTS は、SKILL.md へのパス、スキルのディレクトリへのパス、スキル名、または空のいずれかです。
- 空:
.claude/skills/*/SKILL.mdと**/skills/*/SKILL.mdをグロブします。1つ一致 → それを使用します。複数 → リスト表示してどれかを尋ねます。なし → その旨を伝えて停止します。 - ディレクトリ: その中の
SKILL.mdを使用します。 - 名前: 一致するスキルディレクトリを見つけます。
ベアスキル名は SKILL.md を含むディレクトリ名です。フロントマターの description を読み、それを目の前に置いてください。その文字列がモデルの照合対象となるため、行の設計の主要な入力であり、最終的に編集を提案する対象となります。
その際、長さも測定してください。2つの独立した予算がそれを切り詰め、そのどちらかが低い再現率の結果を生み出し、それはまるで悪い表現のように見えます。
- スキルごとの切り詰め。
descriptionとwhen_to_useは連結され、固定の文字数予算でカットされます — 1,536文字、skillListingMaxDescChars設定で構成可能。カットオフを超えたトリガーテキストはアクティベーションにまったく影響を与えないため、存在しないも同然です。 - リスト全体の予算。これはアクティベーションスイートを実行するリポジトリほど重要になります。 リストには常にすべてのスキル名が含まれますが、その合計文字予算はモデルのコンテキストウィンドウの約1% で、ユーザーがインストールしたすべてのスキルで共有されます。オーバーフローすると、Claude Codeは最も使用頻度の低いスキルから順に説明を削除します。
2つ目の点には、明確に述べる価値のある結果があります。多くのスキルを持つリポジトリでは、スキルが完全に良好な説明を持っていても、その説明がリストに含まれなかったために、ほぼゼロの再現率を記録する可能性があります。その場合、表現を書き換えても何も解決しません。そして削除順序は最も使用頻度の低いものからなので、新しく作成されたスキル(定義上ほとんど呼び出されず、まさにこのスイートを実行する対象)が最も犠牲になりやすいです。これはテスト対象のスキルに対する体系的なバイアスです。
リストに問題がある場合の対策: skillListingBudgetFraction(デフォルト1%)、SLASH_COMMAND_TOOL_CHAR_BUDGET 環境変数(固定文字数)、および skillOverrides を `