Skill Creator

Skill Creator — スキル作成・評価・進化ループ

Claude 公式 skill-creator プラグイン (480行) を吸収。 スキルの作成→テスト→評価→改善→description 最適化の完全反復ループ。

ワークフロー

意図の把握 → ドラフト作成 → テスト実行 → 評価 → 改善 → 繰り返し

Phase 1: 意図の把握 (Capture Intent)

会話の文脈から以下を抽出する:

1. 何をさせるか — スキルの目的
2. いつトリガーするか — description に書くフレーズ/文脈
3. 出力形式 — 期待される結果のフォーマット
4. テストケース — 客観的に検証可能かどうか

エッジケース、入出力形式、成功基準、依存関係について積極的に質問する。

Phase 2: SKILL.md の作成

スキルの構造

skill-name/
├── SKILL.md (必須)
│   ├── YAML frontmatter (name, description 必須)
│   └── Markdown 指示
└── Bundled Resources (任意)
    ├── scripts/    - 決定的/反復タスク用スクリプト
    ├── references/ - 必要時にコンテキストにロードするドキュメント
    └── assets/     - 出力で使うファイル（テンプレート等）

Progressive Disclosure (3段階ロード)

1. metadata (name + description) — 常にコンテキストに (~100語)
2. SKILL.md body — スキルトリガー時のみ (<500行が理想)
3. Bundled resources — 必要時のみ (無制限)

description の書き方

ポイント: 少し「押し強く」書く。 Claude はスキルを使わない方に偏りがちなので、積極的にトリガーされるように:

❌ "ダッシュボードを作るスキル"
✅ "ダッシュボードを作るスキル。データの可視化、メトリクス表示、
   社内データの表示など、ユーザーが明示的に『ダッシュボード』と
   言わなくても使うこと。"

書き方のスタイル

• 命令形を使う
• MUST/NEVER の連発は避ける — 代わりに「なぜ重要か」を説明する
• 理論的に説明する — LLM は賢い、理由を理解すれば正しく動く
• ドラフト → 見直し → 改善 のステップを踏む

Phase 3: テストケース作成

2-3個の現実的なテストプロンプトを作成:

{
  "skill_name": "example",
  "evals": [
    {
      "id": 1,
      "prompt": "ユーザーが実際に言いそうなこと",
      "expected_output": "期待結果の説明"
    }
  ]
}

Phase 4: 評価と改善

改善の考え方

1. 汎化する — テストケースに過適合しない。スキルは何百万回も使われる
2. スリムに保つ — 価値のない部分は削除
3. Why を説明 — 指示の理由を書く。ALWAYS/NEVER より効果的
4. 共通パターンの抽出 — テスト全体で繰り返されるスクリプトは scripts/ に

ループ

1. スキル改善
2. テスト再実行
3. ユーザーレビュー
4. フィードバック反映
5. 満足するまで繰り返し

Phase 5: Description 最適化

description はスキルのトリガー精度を決める最重要要素。

評価クエリの作成 (20個)

• should-trigger (8-10個): 様々な言い回し、カジュアル/フォーマル、暗黙的なニーズ
• should-not-trigger (8-10個): キーワードは似てるが別のニーズ（ニアミス）

良い例: 具体的、ファイル名やコンテキスト付き、省略語やタイポ含む 悪い例: "Format this data" のような抽象的なもの

参照: Ryota スキル一覧

既存スキルとの競合を避けること: