インストール
run claude-with-access-to-the-skill誰向けか
ゼロから skill を作る、既存 skill を直す、改善する、evals を走らせる、分散分析つきの性能対照をする、または description を変えてトリガー精度を上げるときに skill-creator を使う。skill の作成、変更、改善、測定のためであり、名指しされていない市場への公開代行ではない。
より合う前提は、この skill が何をするか、おおよそどうするかを先に整理してから、下書きとテストに入る意思があること。資料にエージェント製品一覧もインストールコマンドもない。リポジトリパスを捏造しない。公式の説明ページは
https://raw.githubusercontent.com/anthropics/skills/main/skills/skill-creator/SKILL.md
3分で最初の試みを終える
推奨パスはインストーラではなく、資料にある過程だ。まず利用者がどの段階にいるかを判断し、先へ進める。おおよその順は：目標とやり方を決める、下書きを書く、テスト用プロンプトを数本用意して claude-with-access-to-the-skill で走らせ、定性と定量の両面から結果を見るのを助ける。
前提：すでに skill にしたい仕事がある。低リスクな最初はファイルを書かない。数文で「この skill は何をするか、だいたいどうするか」を確認し、相手が題材選びか、下書きありか、すでにテスト中かを判断する。要約は、先に感覚で進め evals を飛ばしたいと言ってよいとする。相手が明確に飛ばすなら、無理に計測を開かない。
成功の合図：今どの段にいるかを指せ、次は一段だけ進める。下書きはファイルを変えるので、書く前に置き場所を確認する。名指しされていない評価プラットフォームを先に走らせない。
使用事例
事例一：ゼロから、トリガーする skill を書く。先に何をするかを決め、それから下書きを書く。description が主トリガー機構である。何をするかと、どの状況で使うかの両方を書く。「いつ使うか」はすべて description に置き、本文には書かない。資料は、いまの Claude は undertrigger しやすいと注意するので、記述は十分具体的であること。完了基準は、下書きの description が能力とトリガー状況の両方を含むこと。抜粋に SKILL.md のフィールドテンプレート全文はないので、出ていない必須欄を捏造しない。
事例二：skill がすでに使えるあと、トリガーを改善する。資料は、やり終えたあと（順はなお柔軟でよい）skill description improver を走らせてよいと書く。これはトリガー最適化用の、別の独立スクリプトである。完了基準は、この improver を走らせる準備ができたことであり、評価セットをすべて直したことではない。抜粋にスクリプトファイル名もコマンドラインもないので、呼び出し引数を捏造しない。「別スクリプトがあり、目的はトリガー」という一段だけを確認する。テスト用プロンプトは claude-with-access-to-the-skill で走らせ、定性と定量の評価をする。
使用の境界
過程は柔軟でよいが、職責は利用者がどの段で止まっているかを見極め、進めること。作成ループは：決定、下書き、テスト用プロンプト、評価、再修正。description が「いつ使うか」をすべて担い、本文にトリガー条件を重ねない。Claude は現在、トリガーを控えがちである。
インストーラやリポジトリ内パスを捏造しない。資料にクライアント一覧はなく、description improver の完全なコマンドも書いていない。ここに書いた段階、テスト入口、description の書き方の外は、この説明の範囲外である。ファイルを書く、またはテストを走らせる前に、パスと既存 skill を上書きするか確認する。