skill-router

skill-router スキルの概要

skill-router がすること

skill-router スキルは、複数のスキルを使う Claude Code 環境における最初の振り分け役です。タスクそのものを解決するのではなく、依頼内容を見て最適な専門スキルを判断し、確信を持ってルーティングできないほど依頼が曖昧な場合は確認質問を返します。agent-playbook を検討している人や、スキルベースのワークフローをチームで使いやすくしたい人にとって、skill-router はまず「どれを使うべきか」の迷いを減らしてくれる要のパーツです。

skill-router を入れるべき人

skill-router は、使えるスキルが複数あり、日常的に「どのスキルを使えばいい？」「このプロジェクトを手伝って」「何かスキルを使って対応して」といった依頼を受ける環境に向いています。特に相性がよいのは次のようなケースです。

• エージェントがどのスキルを選ぶかをチームで標準化したい
• スキルライブラリを使い始めたばかりで土地勘がない
• 同じ曖昧な依頼が、レビュー、デバッグ、ドキュメント、テスト、設計のどれにもなり得る

逆に、使うスキルが1〜2個しかなく、毎回どれを呼ぶべきか自分で明確に分かっているなら、skill-router の価値は小さめです。

skill-router が本当に解決する仕事

skill-router の役割は、単なるおすすめ表示ではありません。要件の曖昧な依頼を、次に取るべき具体的な一手へ変換することです。つまり、適切なスキルを選び、理由を示し、進行に必要な最小限の文脈を引き出すこと。多くのスキル運用では、実行品質が問題になる前に、最初の「どれを使うか」でつまずきます。skill-router はそこを埋めるためのスキルです。

skill-router の主な差別化ポイント

よくある「どのツールを使えばいい？」という汎用プロンプトと比べると、skill-router には実務上の強みがあります。

• 間違った専門スキルを選ぶ前の早い段階で発火する前提で設計されている
• ユーザーの意図を利用可能なスキル群に対応付ける、カタログ前提の発想がある
• 意図が曖昧なときに確認質問で補える
• after_complete hook でルーティング判断を記録でき、時間をかけてスキル選定の傾向を可視化しやすい

インストール前に最も重要な確認点

skill-router を導入する前に、まず次の2点を確認してください。

1. ルーティング先として意味のある下流スキル群が実際に揃っているか
2. ユーザーが明確な作業指示ではなく、曖昧な目的ベースで依頼してくることが多いか

skill-router は、整理されたスキル群がある環境でディスパッチャとして最も力を発揮します。逆に、カタログが小さい、古い、あるいは実環境に合わせて大きくカスタマイズされているのに router 側のロジックが追随していない場合、単体では強みが出にくくなります。

skill-router スキルの使い方

skill-router のインストール前提

このリポジトリでは、skill-router は skills/skill-router にあります。README では、symlink ベースのインストール例が案内されています。

ln -s ~/Documents/code/GitHub/agent-playbook/skills/skill-router/SKILL.md ~/.claude/skills/skill-router.md

スキルマネージャー対応の環境なら、インストール先はローカルのスキルディレクトリ構成に合わせて調整してください。重要なのは、SKILL.md が Claude Code の skill loader から想定されるスキル名で見つけられる状態になっていることです。

まず読むべきファイル

素早く見極めたいなら、まず次の2ファイルを確認します。

1. skills/skill-router/SKILL.md
2. skills/skill-router/README.md

SKILL.md には、実際の発火条件、利用可能ツール、ルーティング挙動、利用できるスキルカタログが書かれています。README.md は全体像や例を掴むのに役立ちますが、導入判断に直結する情報の中心は SKILL.md です。

どんなときに skill-router を起動するか

依頼が「どのスキルを選ぶべきか」の段階で曖昧なら、最初に skill-router を使うのが基本です。たとえば次のようなケースです。

• 「このコードベースを手伝って」
• 「これを改善するのに何かスキルを使って」
• 「この PR にはどのスキルを使うべき？」
• 「デバッグなのかリファクタリングなのか自分でも分からないけど助けてほしい」

このリポジトリでは、特にユーザーが “skill”“which”“how to” に触れている場合や、迷いを示している場合に、skill-router をスキル関連依頼のデフォルト入口として位置付けています。

skill-router に必要な入力

skill-router が最もうまく機能するのは、入力に次の情報が含まれているときです。

• タスクの目的
• 対象物の種類: PR、bug、README、test suite、design file、commit など
• 欲しい結果
• どの種類の支援が必要か分からない、という不確実さ

これだけあると、広い確認質問に戻りすぎず、意図をスキルに結びつけやすくなります。

曖昧な依頼を skill-router が振り分けやすいプロンプトにする

弱い入力:

• 「Use a skill for my project」

より良い入力:

• 「I need help reviewing a pull request for a Node.js API. I want feedback on correctness, security, and maintainability. Which skill should I use?」

これが良い理由:

• 何を対象にしているかが明確
• 見てほしい品質観点が示されている
• 候補となるスキルカテゴリが絞られる
• それでも最終的なルーティング判断は skill-router に委ねられている

skill-router の利用パターン例

直接ルーティングしたい場合:

• 「Which skill should I use to write a clean commit message for these staged changes?」
• 「I need to diagnose a failing test suite in a Python service. What skill fits best?」
• 「Use skill-router for Skill Discovery across docs, testing, and refactoring tasks in this repo.」

確認質問が入る前提の曖昧なルーティング:

• 「Help me improve this project before release.」
• 「Use a skill for this design handoff.」
• 「I’m stuck and not sure whether I need debugging, review, or refactoring.」

skill-router で振り分けた後のおすすめ手順

実務では、次の流れにすると使いやすいです。

1. 大まかな依頼内容で skill-router を起動する
2. 確認質問には短くても具体的に答える
3. 推奨されたスキルを確認する
4. 整理された依頼文を持って専門スキルへ切り替える
5. 確認で得た文脈を引き継ぎ、下流スキルが十分な情報から始められるようにする

skill-router の価値はここにあります。曖昧な意図から、実行可能な専門スキル呼び出しまでの受け渡しを圧縮してくれます。

想定される skill-router のカタログ分類

リポジトリ内の記述を見る限り、skill-router は次のような領域を含むカタログを前提にしています。

• core development
• design and UX
• documentation and testing

カタログ例としては、commit-helper、code-reviewer、debugger、refactoring-specialist、figma-designer、そしてドキュメント系スキルが挙がっています。つまり skill-router が最も活きるのは、依頼内容がこうした既存レーンのいずれかに自然に乗る場合です。

skill-router 利用時の実務上の限界

skill-router は専門スキルの代替ではありません。あくまで選定役であり、最終実行役ではありません。やるべきことがすでに十分具体的で、最初から debugger や code-reviewer に直接渡せるなら、先にルーティングを挟むのは単なるオーバーヘッドになることがあります。

また、性能はカタログ品質に依存します。実際にインストールされているスキル群が SKILL.md のカタログとずれている場合、提案が古くなったり、誤解を招いたりします。

押さえておきたいツール権限と挙動

このスキルに許可されているツールは Read、AskUserQuestion、WebSearch、Grep です。実際に特に重要なのは AskUserQuestion で、曖昧さを解消してから推奨するだけで、ルーティング精度は大きく上がります。

さらに、session-logger 向けに “Log skill routing decisions” という理由付きの after_complete hook も定義されています。監査性を重視する場合や、ユーザーがどんな依頼で分類に悩みやすいかを後から分析したい場合には、この実装詳細はかなり有用です。

skill-router スキル FAQ

skill-router は初心者にも向いていますか？

はい。特に、利用可能なスキル一覧が長く、どこから始めればいいか分からない初心者には有効です。skill-router は「X を手伝ってほしい」という曖昧な状態を、「次はこの具体的なスキルを使う」という形に変えて、入口のハードルを下げてくれます。

skill-router は Skill Discovery 専用ですか？

いいえ。skill-router for Skill Discovery は代表的な強みの一つですが、それだけではありません。チーム運用で最初の切り分けを統一したい場面でも有効です。個人がカタログを覚えているかどうかより、一貫した初動トリアージが重要な環境に向いています。

skill-router は普通のプロンプトと何が違いますか？

普通のプロンプトでも「おすすめのスキルを教えて」と頼むことはできます。ただし skill-router は、その振る舞いを再利用可能で明示的に起動できるスキルとしてパッケージ化しています。発火のきっかけ、既知のカタログ、確認質問ロジックが揃っているため、ルーティング工程をより一貫して運用しやすくなります。

どんなときに skill-router をスキップすべきですか？

次のような場合はスキップして構いません。

• すでに正しい専門スキルが分かっている
• 環境内のスキル数がごく少ない
• skill-router 内のカタログが実際の導入済みスキルセットを反映していない
• 曖昧さがほとんどなく、すぐ直接実行したい

カスタムなスキル環境でも skill-router は有効ですか？

有効になり得ますが、前提はカタログを実際のスキル構成と揃え続けることです。router の価値は、正確な対応付けにあります。大きくカスタマイズされた環境では、古いカタログ項目が導入上の最大のリスクになります。

skill-router の導入コストに見合いますか？

同じスキルライブラリを複数人で使う場合や、広すぎて要件が足りない質問がよく来る環境なら、たいていは見合います。逆に、個人利用で頻度も低く、どのスキルを使うかすでに把握できているなら、必須というより任意導入に近い位置づけです。

skill-router スキルを改善する方法

skill-router により良いルーティング信号を渡す

skill-router の結果を最も手早く改善する方法は、最初の入力精度を上げることです。次を含めてください。

• タスクの種類
• 対象の artifact またはターゲット
• 期待する結果
• 言語、repo の範囲、締切などの制約

たとえば「something is broken」よりも、「packages/api の failing CI test を調べて root cause を切り分けたい」のほうが、はるかに適切にルーティングされます。

確認質問には意思決定に必要な粒度で答える

skill-router が追質問してきたときに、「とにかく改善して」のような曖昧な返し方は避けてください。何を改善したいのかを具体化したほうが、選ばれるスキルが変わります。たとえば correctness、readability、docs quality、UX fidelity、test coverage、release readiness のどれを重視するのかを示すと有効です。

skill-router のスキルカタログを最新に保つ

構造的に見て、skill-router 最大の改善ポイントはカタログ保守です。リポジトリで下流スキルが追加・削除・改名されたら、router 側もすぐ更新してください。router の質は、把握している選択肢の質を超えられません。

skill-router の曖昧性解消ルールを強化する

典型的な失敗パターンは、近いカテゴリ同士の重なりです。たとえば debugging と refactoring、documentation と review の境界です。skill-router を改善するなら、次の区別に使う手がかりをもっと明確にすると効果的です。

• diagnosis と code improvement の違い
• review と generation の違い
• design interpretation と implementation planning の違い

実際に曖昧になりやすい依頼例を skill-router に追加する

このスキルにはすでに直接ルーティング例と曖昧な例がありますが、導入を進めやすくするなら、実際の社内依頼に近い例をさらに足すと有効です。たとえば:

• release prep
• failing CI with unknown root cause
• “make this PR ready”
• converting design files into implementation tasks

こうした例があると、ユーザーはルーティングしやすい言い回しを真似しやすくなります。

ルーティングログを使って skill-router を磨く

skill-router は session-logger を通じてルーティング判断を記録するので、利用できるならそのログを見返してください。着目点は次の通りです。

• 確認質問が何度もループしているケース
• 継続的に誤ルーティングしている依頼
• よく出るのに強く対応するスキルがない意図

このフィードバックループは、skill-router を時間をかけて改善していくうえで最も実践的な方法の一つです。

最初の推薦が微妙でも skill-router をすぐ見切らない

最初の推薦が惜しいが少し違う、というときに、すぐスキル自体を諦める必要はありません。足りない文脈を足して依頼を言い換えてみてください。

• 対象の artifact は何か？
• 必要なのは diagnosis、review、generation、restructuring のどれか？
• 成功をどう定義するか？

これだけで、広すぎる推薦が2回目には正しい専門スキルへの受け渡しに変わることがよくあります。

チーム導入を進めるなら skill-router の運用ルールを一つ決める

実用的なルールとしては、「ユーザーの依頼が、明確に定義された作業の実行ではなく、どんな助け方が適切かを探す内容なら、まず skill-router を使う」と決めるのがおすすめです。こうすると skill-router を価値の高い初動トリアージに集中させられ、あらゆるフローに無理やり差し込む運用を避けられます。