skill-distillery

Skill Distillery

生の素材を強力なスキルへと蒸留します。記事、講演、フレームワーク、最近の AI 関連の取り組み、あるいはアイデアだけでも、skill-distillery はボトムアップで戦略を抽出し、対話型で設計の行き届いたスキルを構築します。

中核となる洞察： 優れたスキルとは、コンテンツを再構成したものではなく、戦略を蒸留したものです。5,000 語の記事を 300 行のスキルにするには、段落を再フォーマットするのではなく、原則、メンタルモデル、意思決定フレームワークを抽出します。

クイックスタート

記事やフレームワークから作成する：

/skill-distillery https://example.com/great-article-about-design-systems /skill-distillery ~/Documents/talk-transcript.md

最近の AI 関連の取り組みから作成する：

/skill-distillery capture — 「X の優れたプロセスを見つけたばかりです。これをスキルにするのを手伝ってください」

説明から作成する：

/skill-distillery — 「API ドキュメントをより適切に書けるよう支援するスキルがほしいです」

既存のスキルを監査する：

/skill-distillery audit ~/.claude/skills/my-skill /skill-distillery review — 「language-market-fit スキルを評価してもらえますか？」

既存のスキルに追加する：

/skill-distillery add reference — 「my-skill に新しいリファレンスファイルを追加したいです」

---

中核となる原則

以下は、skill-distillery が行うすべてのことに当てはまります。

1. コンテンツの再構成よりもボトムアップの統合を優先 — ソース素材から原則とメンタルモデルを抽出します。再フォーマットするのではなく、蒸留します。

2. デフォルトで対話型にする — タップして選べる選択肢には AskUserQuestion を使います。一度に質問するのは 2～3 個にとどめ、質問をずらりと並べないでください。すでにコンテキストがある場合は、手短に進められる方法を提示します。

3. 構築前に提案する — ファイルを作成する前に、統合内容、アーキテクチャ、進め方を必ず提示し、ユーザーの承認を得ます。各意思決定の段階で確認を待ちます。

4. 段階的に情報を開示する — SKILL.md は簡潔に保ちます（200～300 行）。詳細はリファレンスファイルに記載します。ユーザーのニーズに応じて、必要なものだけを読み込みます。

5. 明確なデフォルトを用意する — 実績のあるスキルの対話パターン（design-portfolio-assistant のディスカバリーフェーズ、language-market-fit のモード検出など）を提案します。ユーザーは変更できますが、デフォルトは適切なものにします。

6. 調査は必要に応じて行い、デフォルトでは行わない — ほとんどのスキル作成に調査は必要ありません。外部 API／ライブラリが関係する場合、またはユーザーが明示的に求めた場合にのみ調査します。以下の「調査プロトコル」を参照してください。

7. ユーザー固有の目標に合わせる — 一般的なスキル作成のアドバイスではありません。すべての判断を、このユーザーがこの目的のために構築しているものに合わせます。

8. つまずきやすい点こそ、最も価値の高い情報 — どのスキルでも最も価値があるのは、Claude がよく失敗するポイントです。すべてのスキルに、具体的な失敗要因を「Y だから X をしてはいけない」という形式で記述した、専用のつまずきやすい点のセクションを設けてください。つまずきやすい点は、理論上のアンチパターンではなく、Claude の失敗パターンを予測して導き出します。

9. 対象に応じて適切な厳密さにする — 個人用の簡易スキルは簡潔に保ち、チーム用のスキルには安全に共有するために必要なテストを含め、公開用のスキルには評価、まっさらなエージェントでの検証、README と公開に向けた仕上げを含めます。スキルを共有する可能性がある場合は、対象エージェントについて早い段階で確認します。Claude 専用か汎用かによって、ツールや対話方法の選択が変わるためです。

---

厳密さのレーン

早い段階でレーンを選び、それに合わせて調査の深さ、成果物の数、検証方法を決めます。

レーン	使用する場面	デフォルトの出力	検証
個人向けクイック	スキルを使うのが、コンテキストを十分に把握している執筆者1人の場合	簡潔な SKILL.md、任意のメモ	1～3件のスモークテスト用プロンプト
チーム内向け	スキルをチームメイトや複数のエージェントが再利用する場合	SKILL.md と必要な情報に絞ったリファレンス、README は任意	トリガー／非トリガーのプロンプトと代表的なタスク
公開向け・完成版	スキルを公開する、または完成度の高い成果物として提示する場合	SKILL.md、README、評価パック、段階的なリファレンス	評価パック、新しいエージェントによるテスト、互換性レビュー

どのレーンでも、徹底的な調査は有益です。違いは、その内容をどこに置くかです。調査メモや根拠は内容の整理に役立て、実行時のスキルファイルには実行に不可欠な指示だけを含めます。

---

調査プロトコル

スキルの作成時に、いつ、どのように調査するかを定めます。

調査を開始する場合：

• 最新のドキュメントが必要な外部 API やライブラリがスキルに関係する
• ベストプラクティスが急速に変化する分野である（フレームワーク、デプロイパターン）
• 監査で、スキルが古いライブラリやパターンを参照していることが判明した
• ユーザーが「X について調査できますか？」と明示的に依頼した

調査を開始しない場合：

• 情報源の内容だけで完結している（記事、講演）
• ユーザーがすでにその分野に詳しい
• スキルが社内プロセスや規約に関するものである
• 外部ツールを参照しないシンプルなスキルである

確認方法： 何かを開始する前に、次の質問を1回だけ行います。

これは [X] に関する内容です。最新のベストプラクティスを調査しますか。それとも、十分なコンテキストがありますか？

AskUserQuestion が利用できる場合：

• はい、先に調査してください — 正確な実装のため、最新のドキュメントを取得します
• いいえ、コンテキストは十分です — 現在の情報を使って進めます

実行方法： 範囲を明確にした具体的な質問を用意し、Sonnet エージェントを2～3個並列で起動します（高速で低コスト、情報取得に適しています）。「X についてすべて調査する」ではなく、実際に必要な範囲に絞ります。

エージェントへのプロンプト例：

• 「公式ドキュメントから Supabase の RLS に関する最新のパターンを取得してください」
• 「React Native のナビゲーションライブラリに関する2026年のベストプラクティスを見つけてください」
• 「[library] が現在も積極的にメンテナンスされているか確認してください」

Context7 MCP が利用できる場合は、ライブラリのドキュメントに resolve-library-id → query-docs を使用します。

調査結果の使い方： 調査結果を統合と方針策定に活用し、原則やアーキテクチャの検討に役立てます。生の調査結果をそのままリファレンスファイルに詰め込まないでください。先に重要な調査結果をユーザーに提示してから、作業を進めます。

---

エントリーポイントの判定

ユーザーが提供した内容を判定し、適切なワークフローに振り分けます。

ユーザー入力	振り分け先
URL（http/https）	workflows/from-source-material.md
記事／ドキュメント／トランスクリプトのファイルパス	workflows/from-source-material.md
SKILL.md またはスキルディレクトリのファイルパス	workflows/audit-existing-skill.md
引数に「audit」「review」「evaluate」が含まれる	workflows/audit-existing-skill.md
「capture」「just did」「turn this process」が含まれる	workflows/from-recent-work.md
「add reference」「add workflow」「add script」が含まれる	workflows/add-component.md
作成したいものの説明	workflows/from-description.md
引数なし／内容が不明確	何をしたいかを尋ねます

検出ロジック

1. $ARGUMENTS に URL が含まれているか確認します → from-source-material
2. $ARGUMENTS にファイルパスが含まれているか確認します → ファイルを読み、スキル（name／description を含む YAML フロントマターがある）か、ソース資料かを判定します
3. $ARGUMENTS に次のキーワードが含まれているか確認します：「audit」、「review」、「evaluate」、「improve」 → audit-existing-skill
4. $ARGUMENTS に次のキーワードが含まれているか確認します：「add reference」、「add workflow」、「add component」 → add-component
5. $ARGUMENTS に次のキーワードが含まれているか確認します：「capture」、「just did」、「turn this into」 → from-recent-work
6. $ARGUMENTS に説明が含まれている場合 → from-description
7. 引数がない場合は、次のように尋ねます。

AskUserQuestion が利用できる場合：

• ソース資料をスキルに変換する — 記事、講演、またはフレームワークがあります
• 最近の作業を記録する — たった今行った作業のプロセスを保存したいです
• やりたいことを説明する — スキルに求めることを説明します
• 既存のスキルを監査する — 所有または見つけたスキルを評価します

それ以外の場合は、次のように尋ねます：「何をしたいですか？ (1) ソース資料をスキルに変換する、(2) 最近のプロセスを記録する、(3) やりたいことを説明する、(4) 既存のスキルを監査する」

ワークフローを選択したら、それを読み、指示に厳密に従ってください。

---

リファレンス一覧

補足情報はすべて references/ にあります。

ファイル	内容	読み込むタイミング
official-spec.md	2026 年のスキル仕様 — フロントマター、機能、形式	スキルの作成または監査時
synthesis-patterns.md	ソース資料から原則を抽出する方法	ソース資料または最近の作業を起点とする場合
architecture-decisions.md	シンプル型とルーター型、それぞれのファイル形式を使う場面	アーキテクチャ提案の手順（すべてのワークフロー）
interactive-design-patterns.md	発見、モード、待機ゲート、AskUserQuestion	戦略の手順と監査ワークフロー
quality-checklist.md	検証チェックリスト	検証の手順（すべてのワークフロー）
evaluation-patterns.md	厳密性の区分と評価パックの設計	検証を計画する前
cross-agent-compatibility.md	エージェント間レビューガイド	エージェント間レビューの手順（すべてのワークフロー）
independent-review-brief.md	独立レビュー用サブエージェント向けの事前作成済み指示	ビルドワークフローの任意のレビュー手順

ワークフロー一覧

ワークフロー	目的
from-source-material.md	記事／講演／フレームワーク → スキル（主要ワークフロー）
from-description.md	白紙の状態 → アイデア出し → スキル
from-recent-work.md	AI の作業プロセスを再利用可能なスキルとして記録する
audit-existing-skill.md	7 つの評価観点によるフレームワーク全体の監査
add-component.md	既存のスキルにリファレンス／ワークフロー／スクリプト／テンプレートを追加する

テンプレート

templates/ にすぐにコピーして使える出発点があります。

テンプレート	使用する場面
simple-skill.md	200 行未満の単一ワークフロースキル
router-skill.md	共通原則を持つ複数ワークフローのスキル
eval-pack.md	Team Internal または Public Polished の評価パック