# Skill Creator

> スキル作成・改善・評価スキル。「新しいスキル作って」「スキルを改善して」「スキルをテストして」「スキルのdescription最適化して」と言われたら必ず使う。Claude 公式 skill-creator を吸収し、Progressive Disclosure + eval ループ + description 最適化を完全サポート。

- Skill: `tanakaryotadayo-wq/skill-creator` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tanakaryotadayo-wq/skill-creator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tanakaryotadayo-wq/skill-creator/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tanakaryotadayo-wq (https://skillmd.com/u/tanakaryotadayo-wq)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/tanakaryotadayo-wq/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個の現実的なテストプロンプトを作成:

```json
{
  "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 スキル一覧

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

| スキル | トリガー |
|--------|---------|
| `mcp-mastery` | MCP サーバー開発・統合・運用 |
| `code-review` | コードレビュー・バグ検出 |
| `code-simplifier` | リファクタ・簡素化 |
| `cbf-review` | CBF 5軸品質判定 |
| `pcc-evolution` | PCC 品質パイプライン |
| `db-agent` | DB 監査・改善提案 |