skill-finder

スキルファインダー

厳選されたカタログの外で見つかったスキルを採用すると、カタログ内のフローにはない、次の2つの失敗要因があります。

1. 品質の低いコンテンツ — レジストリによって審査の厳しさは大きく異なり、SEO目的でスクレイピングされたものもあります。
2. レジストリの見落とし — Tier 1の公式ソースでニーズをすでに満たせる場合があり、最初にGitHubでgrepすると手間が無駄になり、ノイズの多い一覧に行き着きます。

このスキルは、複数のソースを意図的に検索し、waxaの評価に合格していないものの採用を拒否するためのものです。

呼び出すタイミング

ユーザーから明示的に依頼された場合のみです。次のような表現がトリガーになります。

• 「<X>のスキルを探して」
• 「<X>向けのスキルはありますか？」
• 「採用する前に<owner/repo>をスキルとして評価して」
• 「レジストリで<X>を検索して」

使用しない場合：

• カタログに適合するものがある → ただちに停止し、代わりにskill-selectorのPhase 1を使うようユーザーに伝えます。Tier 1〜4の検索を続けず、インストール手順も提案せず、他のソースも調査しないでください。既存のスキルは外部のもので改善できそうな場合でも、カタログ内の適合するスキルが回答です。Phase 1の方針に従ってください。
• 繰り返し発生しない単発のタスク → その場で解決し、一度しか使わないスキルは採用しないでください。
• ユーザーが発見を依頼していない → メタスキルのため、自動的に実行されることはありません（ユーザーレベルのCLAUDE.md「Skill 利用方針」を参照）。

事前確認（必須の最初の手順）

他のことをする前に、ユーザーが示したニーズに照らしてskill-selector/references/catalog.mdの項目を確認してください。該当する項目がある場合：

1. 該当するカタログ項目をユーザーに伝えます。
2. インストールにはskill-selector（Phase 1）を呼び出すよう勧めます。
3. 停止します。 以下のワークフローは実行しないでください。Tier 1以上のソースも調査しないでください。

カタログを確認し、約30秒以内に一致する項目が見つからなかった場合に限り、この確認を越えて先に進んでください。

ソース

優先度の階層です。常に最上位から始め、上位の階層に適合するものがない場合にのみ、次の階層へ進んでください。

Tier	ソース	形式	備考
1	anthropics/skills	GitHubリポジトリ、約30個のファーストパーティスキル	最も信頼できます。インストール：apm install anthropics/skills/skills/<name>（リポジトリ内ではskills/の下にあります）。
1	anthropics/claude-plugins-official	プラグインマーケットプレイス	公式プラグイン（frontend-design / mcp-server-dev / code-review / ralph-loop / external_plugins/...）。
2	majiayu000/claude-skill-registry	毎日クロールされ、重複排除とセキュリティスキャンが行われるソース横断インデックス	最適な検索ハブです。パス形式owner/repo/skills/nameは、そのままAPMで使用できます。
2	VoltAgent/awesome-agent-skills	組織別にまとめられたawesomeリスト（MIT、活発に更新）	各項目はofficialskills.shを経由します。採用する前に、リンク先のGitHubリポジトリを確認してください。
3	ComposioHQ/awesome-claude-skills	より幅広く、選定基準が緩やかなawesomeリスト	項目は推奨ではなく、候補として扱ってください。
3	obra/superpowers	スキルバンドル、方法論を重視（TDD / subagent / ブレインストーミング）	高品質ですが、独自の方針が強いため、適合性を慎重に確認してください。
4	GitHub topic:claude-skill / topic:agent-skills / path:**/SKILL.md	直接検索	最終手段です。スター数ではなく、最近更新された順に並べてください（スター数上位のリポジトリは、たいていスキルではなくawesomeリストです）。
NG	agent-skills.cc	SEO目的のスクレイピング、スター数のみを評価指標とし、APMと互換性なし	ここからソースを取得しないでください。元のGitHubリポジトリを見つけるための別名検索には使えますが、主な推奨元としては使わないでください。

ワークフロー

0. 導入前のカタログ確認（上記を参照）。 skill-selector/references/catalog.md に適合する項目がある場合は、そこで中止して skill-selector に委ねてください。該当するカタログ項目がない場合に限り、ステップ 0 以降に進んでください。
1. 繰り返し発生するニーズを明確にします。 スキルが正当化されるのは、繰り返し発生するタスクの種類がある場合に限られます。ユーザーがその種類を挙げられない場合は、導入せず、その場で解決してください。
2. 上位から順に確認します。 まず Tier 1 を確認します。最初に利用可能な候補が見つかった時点で中止し、Tier 1 に該当する候補がある場合は下位の Tier を調査しないでください。候補ごとに、スキル名、解決済みの GitHub URL、1 行の説明、最終更新日、ライセンスを記録します。
3. 評価基準を適用します。 候補は、以下の 7 つの観点すべてで許容できる場合に限り合格です。
   • 適合性 — スキルの「Use when...」は、プロジェクトのタスクに実際に合致していますか？タイトルではなく、説明を読み直してください。
   • 非重複性 — プロジェクトにすでにインストールされているスキル群で、このニーズはカバーされていますか？「Fit ✓」の候補でも、すでに導入済みのスキルと重複する場合は却下してください（または、カバーできていないことが明らかな 1 つのプロジェクトに限って、プロジェクト単位で固定してください）。よくある重複の組み合わせ：スキル作成スキルと superpowers:writing-skills + empirical-prompt-tuning + waxa-eval、テストスキルと playwright-test、dotfile スキルと chezmoi-management。重複するスキルは、独自の効果がないまま、すべての会話でコンテキストを消費します。
   • メンテナンス状況 — 最終コミットは最近ですか？上流での活動が確認できますか？
   • ライセンス — SPDX が記載されており、利用するプロジェクトと互換性がありますか？
   • フロントマターの健全性 — name はディレクトリ名と一致していますか？説明は 1024 文字以内で、（superpowers:writing-skills の CSO に従い）発動条件を示す形式になっていますか？
   • 本文の品質 — 「When NOT to use」が明記されていますか？具体的なパターンが示されていますか、それとも曖昧な助言にとどまっていますか？
   • フットプリント — 本文の長さ、常時読み込みではなく必要時に読み込むリファレンスの有無、スキル間の依存関係を確認します。
4. waxa 監査（推奨）。 eval ゲートの予算を使う前に、npx @mizchi/waxa audit <candidate-skill-dir> を実行し、構造上の問題を低コストで洗い出してください。フロントマターの形式、本文の長さ、「When NOT to use」の欠如、不審なスクリプト、LICENSE の欠如に加え、apm audit による隠し Unicode（プロンプトインジェクション）のスキャンも確認できます。監査エラーがある候補は、eval ゲートで LLM の時間を使わずに却下するのが妥当です。
5. waxa eval ゲート（必須）。 実証的な評価なしに導入することこそ、このスキルが防ごうとしている失敗です。最終候補ごとに、以下を実施してください。
   • サンドボックスプロジェクトに一時的にインストールします：apm install <owner>/<repo>/skills/<name>（またはローカル監査の場合はシンボリックリンクを使用します）。
   • プロジェクトで実際に繰り返し発生するタスクに合致した tasks/*.yaml を 1～2 個作成します。動作するテンプレートについては、skill-selector/evals/ と nix-setup/evals/（waxa 0.2.0 のスキルローカルのレイアウト）を参照してください。
   • trials_per_task: 2 以上で waxa run を実行します。
   • 台帳が収束するまで繰り返します（waxa iterate）。収束とは、曖昧な点が 0 件の実行が 2 回連続することを指します（empirical-prompt-tuning を参照）。
   • 2 回の反復を経ても曖昧な点が解消されず、減少傾向もない場合は、収束不能と見なし、却下します。
6. 判断して固定します。 導入する場合は、必ず参照を固定します。固定は必須であり、交渉の余地はありません。
   • カタログに昇格 — eval に合格し、2 つ以上のプロジェクトで問題なく使用された場合は、そのスキルを使うべきプロジェクトの条件とともに skill-selector/references/catalog.md への追加を提案します。
   • プロジェクト単位で固定 — 1 つのプロジェクトに適合する場合は、apm view <repo>（または上流のリリースページ）で解決した タグまたは SHA を使って、そのプロジェクトの apm.yml に追加します。waxa eval に合格した正確な参照先に固定してください。eval の後に導入し、eval で評価した参照先に固定します。本番プロジェクトでは、可変の参照先（main、master、HEAD）は禁止です。
   • 却下 — 同じ候補が四半期ごとに再評価されないよう、却下理由を references/rejection-log.md（このスキル）および／またはプロジェクト独自の docs/skills-rejected.md に記録します。よくある却下理由：ライセンスの欠如、本文の品質が最低基準未満、非重複性の観点で不合格（インストール済みのスキル群ですでにカバーされている）、メンテナンス状況のシグナルが弱すぎる。
7. フォークして修正する方法。 候補があと一歩で条件を満たさない場合は、呼び出し側で欠点を回避するより、mizchi/skills/<name>（またはプロジェクトのローカルスキルディレクトリ）にフォークして作り直すことを優先してください。上流 PR で差分を解消できるよう、変更内容を記録してください。

ソース固有の解決メモ

• anthropics/skills：スキルは skills/<name> の下にあります。インストール文字列：apm install anthropics/skills/skills/<name>（パスに「skills/skills」が含まれていますが、誤記ではありません）。

• anthropics/claude-plugins-official：external_plugins/（asana、linear、playwright、serena、laravel-boost、github、gitlab、firebase、terraform）が含まれています。これらはプラグインであり、スキルそのものではありません。APM 依存関係として扱う前に、プラグインマニフェストで SKILL.md が公開されていることを確認してください。

• majiayu000/claude-skill-registry：独自の sk CLI が同梱されていますが、使用する必要はありません。パスが分かれば、apm install owner/repo/skills/name を実行できます。探索にはレジストリのウェブ UI／データファイルのみを使用してください。

• VoltAgent/awesome-agent-skills：README は組織別（Anthropic／Stripe／HashiCorp／Cloudflare／Sentry など）にまとめられています。次のコマンドで項目を抽出します。

  curl -sL https://raw.githubusercontent.com/VoltAgent/awesome-agent-skills/main/README.md \
    | grep -oE '\[[^]]+\]\(https?://officialskills\.sh[^)]+\)'
  

  各 officialskills.sh の URL は GitHub リポジトリにつながっています。評価する前に、そのリポジトリまでたどってください。

• GitHub トピック検索：API を使用してください。topic:claude-skill（1.4k リポジトリ）と topic:agent-skills（4.3k）はどちらもノイズが多いため、SKILL.md の有無と最近のアクティビティで絞り込んでください。path:SKILL.md 修飾子を使うと候補を絞り込めます。Tier 3 を超えるとスター数はほとんど参考になりません（スター数上位のリポジトリはスキルではなく、awesome リストです）。

waxa 評価テンプレート

<owner>/<repo>/skills/<name> にある候補について、次のコマンドでひな型を作成します。

evals/
└── <name>/
    ├── eval.yaml
    └── tasks/
        ├── scenario-typical.yaml
        └── scenario-edge.yaml

eval.yaml のひな型：

name: <name>-eval
skill: <name>
version: "0.1"

config:
  trials_per_task: 2
  timeout_seconds: 180
  parallel: false
  executor: claude-cli   # mock for smoke; claude-cli for real eval
  model: claude-opus-4-8

graders:
  - name: <task-specific>
    type: text | code | llm | self_report
    config: { ... }

tasks:
  - "tasks/*.yaml"

このリポジトリでの有効な参照先：skill-selector/evals/eval.yaml、nix-setup/evals/eval.yaml（waxa 0.2.0 のスキルローカルレイアウト）。

よくある間違い

間違い	修正方法
すべての Tier を並行して調査する	上位から順に進めます。最初に適合するものが見つかった時点で終了します。
事前のカタログ確認を省略する	必ず最初に skill-selector/references/catalog.md を確認してください。ニーズがカタログで満たされる場合は、直ちにそちらに任せ、Tier 1 以降の調査には進まないでください。特に playwright-test／cloudflare-deploy／gh-fix-ci の項目は、誤って上位の Tier に移行しやすいため注意してください。
「Fit ✓」だけを根拠に採用する	重複がないことは別の評価軸です。ユーザーが明示したニーズに適合しても、インストール済みのスキルと重複する場合（例：anthropic の skill-creator が superpowers:writing-skills ＋ empirical-prompt-tuning ＋ waxa-eval と重複する場合）、そのスキルは却下します。コストは会話ごとのコンテキストであり、採用の見返りには独自の価値が必要です。
却下時に references/rejection-log.md の記録を省略する	却下理由の記録には 30 秒しかかからず、3 か月後にスター数が増えた候補を再評価するのを防げます。このログはスキル探索の実行記録として永続的に残る成果物であり、waxa-eval の評価台帳と同じ役割を果たします。
推薦先として agent-skills.cc を挙げる	情報源は SEO スクレイピングです。GitHub の別名検索にのみ使用してください。主要な推薦先として使ってはいけません。
waxa の評価を省略する（「README に問題がなさそうだから」）	禁止です。評価なしの採用こそ、このスキルが防ぐ失敗です。
main／master を固定する	apm view <repo> でタグまたは SHA を解決し、明示的に固定してください。
組織への所属を品質の根拠にする	有名な組織のリポジトリだからといって、自動的に信頼してはいけません。引き続き評価基準を適用してください。Anthropic が公開したスキルは、まれな例外です。
以前に却下したスキルを再評価する	最初に docs/skills-rejected.md を確認してください。却下理由を記録しておくことで、四半期ごとに再評価を繰り返す手間を防げます。
Tier 1～3をくまなく調べずにTier 4に進む	コストの非対称性が大きく、GitHub 検索はノイズが多い一方、厳選された Tier は事前に候補が絞り込まれています。

関連項目

• skill-selector — Phase 1 のカタログ選定。このスキルより必ず先に実行してください。Phase 1 でニーズが満たされる場合は、skill-finder を呼び出さないでください。
• apm-usage — インストール／固定手順に使用する apm.yml の構文
• empirical-prompt-tuning — waxa の評価ゲートの基盤となる収束／発散のセマンティクス
• superpowers:writing-skills — 評価基準を通過する候補がない場合、無理に適合度の低いものを採用せず、自分でスキルを作成する方法