| name | curated-skill-creator |
| description | 既存のスキルやインターネット上の類似事例をリサーチし、ユーザーの要望と組み合わせて高品質なClaude Codeスキルを作成するスキル。新しいスキルを作りたい、スキルのアイデアがある、こういうワークフローを自動化したい、といった場面で使う。既存のskill-creatorとの違いは、インターネット上の類似スキルやプロンプト、ベストプラクティスをリサーチして取り込むフェーズがあること。スキルを作りたい、ワークフローをスキル化したい、と言われたらこのスキルを使うこと。 |
curated-skill-creator
ユーザーの「こういうことがしたい」を出発点に、インターネット上の類似事例をリサーチし、良いところを取り込みながらClaude Codeスキルを鍛え上げるスキル。
既存のskill-creatorがドラフト→テスト→改善のループに特化しているのに対し、このスキルはリサーチと統合に重点を置く。世の中にすでにある知見を活かして、車輪の再発明を避けつつ、ユーザーの文脈に合ったスキルを作る。
ワークフロー概要
意図の理解 → 仮説ドラフト → リサーチ → 分析・提示 → 取捨選択 → 統合・完成
各フェーズを対話的に進める。いきなり完成品を作ろうとせず、ユーザーとの対話で方向性を固めてからリサーチし、リサーチ結果を見てからまた対話する。
Phase 1: 意図の理解
ユーザーに聞くこと:
- 何を実現したいか: どんな作業を自動化・効率化したいか。具体的なユースケースがあれば聞く。
- どんな場面で使うか: どういうときにこのスキルを呼び出すことを想定しているか。
- 既存の手作業フロー: 今はどうやっているか。手動でやっている手順があれば、それがスキルの骨格になる。
- こだわりポイント: 特にこうあってほしい、という点があれば。
会話の中にすでにヒントがある場合（例: 直前のやりとりを「これをスキルにしたい」と言われた場合）は、そこから情報を抽出してユーザーに確認する。ゼロから全部聞くのではなく、わかっていることは先に提示して確認する。
Phase 2: 仮説ドラフト
意図が掴めたら、まず仮説としてスキルの骨格を作る。この段階では完成度は求めない。重要なのは:
- スキルのワークフロー（どういう手順で何をするか）
- 入力と出力のイメージ
- トリガーとなるフレーズ
- スキルが使うツールやリソース
この仮説ドラフトをユーザーに見せて、「方向性としてはこういう感じですか？」と確認する。ここでのフィードバックが、次のリサーチフェーズの方向性を決める。
ドラフトは実際にSKILL.mdの形式で書く:
---
name: skill-name
description: トリガー条件と概要
---
本文にはワークフローの各ステップ、使用するツール、出力形式を含める。
Phase 3: リサーチ
仮説ドラフトの方向性が固まったら、インターネットで類似の事例を調べる。これがこのスキルの核心。
3-1: 検索戦略
以下の3つの軸で調べる:
a) Claude Code スキル
- GitHubで
SKILL.md や claude skills を含むリポジトリを検索
- 同じドメインのスキルがあれば、その構造とアプローチを確認
b) AIプロンプト・ワークフロー
- 他のAIツール（GPTs、Cursor rules、Copilot instructions等）で同様のことを実現しているもの
- プロンプトエンジニアリングのパターン集
c) ドメインのベストプラクティス
- スキルが扱うドメイン自体のベストプラクティス記事
- 例: テスト自動化スキルなら、テスト設計のベストプラクティスも調べる
3-2: 検索の実行
WebSearchとWebFetchを使い、並列で複数の検索を行う。検索クエリの例:
- "claude code skill" {ドメインキーワード}
- "SKILL.md" {ドメインキーワード} site:github.com
- "cursor rules" {ドメインキーワード}
- "GPT instructions" {ドメインキーワード}
- {ドメインキーワード} "best practices" workflow automation
最低3つ、できれば5つ以上の事例を集める。見つかった事例は、それぞれの中身を読んで理解する。
3-3: リサーチノートの作成
見つけた事例ごとに以下を整理する:
- 出典: URL
- 概要: 何をするスキル/プロンプトか
- 良い点: 参考にできそうなアプローチ、構造、テクニック
- 懸念点: そのまま取り込むと問題がありそうな点
- 仮説ドラフトとの差分: 自分たちのドラフトと比べて何が違うか
Phase 4: 分析と提示
リサーチ結果をユーザーに構造化して提示する。
提示の形式
事例ごとにまとめを見せつつ、特に以下を明確にする:
- 共通パターン: 複数の事例に共通して見られるアプローチ。これは業界のベストプラクティスの可能性が高い。
- ユニークなアイデア: 1つの事例にしかないが、取り込む価値がありそうなもの。
- 仮説ドラフトとの対比: 自分たちのドラフトが既存事例と比べて足りていない点、逆に優れている点。
ユーザーへの問いかけ
事例を提示したうえで、以下を聞く:
- 「この中で取り込みたいアプローチはありますか？」
- 「逆に、これは自分たちのスキルには合わないと思うものはありますか？」
- 「仮説ドラフトの方向性を変えたくなりましたか？」
ユーザーが選択しやすいように、取り込み候補を具体的に挙げて「これを取り込むとこう変わります」と説明する。丸投げの「どうしますか？」ではなく、提案+確認の形を取る。
Phase 5: 統合と仕上げ
ユーザーのフィードバックを受けて、仮説ドラフトとリサーチの知見を統合する。
統合の進め方
- 構造の決定: リサーチで見つかった良い構造パターンがあれば採用する。ただし、ユーザーの文脈に合わない複雑さは持ち込まない。
- 内容の統合: 取り込むことにしたアイデアを、仮説ドラフトの骨格に組み込む。コピペではなく、全体の流れに自然に統合する。
- 独自性の確保: 既存事例の寄せ集めではなく、ユーザーの文脈に最適化されたスキルにする。リサーチは素材であって、完成品ではない。
スキル作成の原則
以下を意識してSKILL.mdを書く:
- Progressive Disclosure: メタデータ（~100語）→ SKILL.md本文（~500行以内）→ 参照ファイル（必要時のみ読み込み）の3層構造
- なぜを説明する: 「こうしろ」ではなく「こういう理由でこうする」。LLMは理由がわかると柔軟に応用できる。
- 具体例を入れる: 抽象的な指示だけでなく、Input/Outputの例を含める。
- ユーザーとの対話ポイントを明示する: どのタイミングでユーザーに確認を取るかを明記する。
- スクリプトの分離: 繰り返し使う処理はscripts/に切り出し、SKILL.mdから参照する。
ディレクトリ構造
必要に応じて以下の構造で作成する:
skill-name/
├── SKILL.md # 必須: フロントマター + 指示
├── references/ # 任意: 必要に応じて読み込むドキュメント
│ └── domain-guide.md
├── scripts/ # 任意: 繰り返し使うスクリプト
│ └── helper.py
└── assets/ # 任意: テンプレートやリソース
└── template.md
シンプルなスキルならSKILL.md単体で十分。無理にディレクトリ構造を複雑にしない。
完成前チェック
スキルを完成させる前に以下を確認する:
Phase 6（任意）: テストと改善
スキルが完成したら、必要に応じてテストを行う。
- テストプロンプトを2-3個考えてユーザーに確認する
- 実際にスキルを使ってタスクを実行し、結果を評価する
- フィードバックに基づいて改善する
本格的なeval（定量評価、ベンチマーク等）が必要な場合は、既存のskill-creatorスキルのeval機能を使う。このスキルの役割はリサーチと統合までで、eval基盤の再実装はしない。
Tips
リサーチがうまくいかないとき
- 検索キーワードを変えて再検索する。ドメインの言い換え、英語/日本語の切り替えを試す。
- 完全に同じスキルがなくても、部分的に参考になるものを探す。「テスト自動化」のスキルが見つからなくても、「CI/CDパイプライン」のスキルの構造は参考になるかもしれない。
- 見つからないこと自体が有用な情報。「まだ誰もやっていない」なら、ゼロから設計する正当な理由になる。
ユーザーが急いでいるとき
リサーチフェーズを省略して、仮説ドラフトをそのまま仕上げることも可能。ユーザーが「リサーチはいいから早く作って」と言ったら、Phase 2からPhase 5に直行する。リサーチは価値を加えるものであって、必須のゲートではない。
日本語と英語
- ユーザーが日本語で話しているなら、SKILL.mdも日本語で書く（国際共有が目的でない限り）。
- リサーチは英語でも日本語でも行う。Claude Codeスキルは英語圏の方が事例が多い。
