npx skills が 70 以上のエージェントにスキルを配る仕組みを整理する

エージェントごとに散らばったスキル定義を一括管理する

Claude Code には CLAUDE.md、Codex には AGENTS.md といった形で、各エージェントが独自の設定ファイルを要求します。プロジェクトをまたぐと、同じ設計ガイドラインを 5 種類の形式で書き直すことになります。skills はこの問題に対して、SKILL.md という共通形式で定義されたスキルを、各エージェントのディレクトリに展開する CLI として設計されています。対象は OpenCode、Claude Code、Codex、Cursor に加えて 73 のエージェントが列挙されており、数としてはかなり広いカバー範囲です。ただし、各エージェントの設定形式の変換がどの程度の深さで行われているかは、リポジトリの説明だけからは判断できません。ここは実際に使う前に、自分のエージェントでの出力結果を確認するのが安全です。

Git 認証を再利用し、トークンをプロセスに渡さない設計

プライベートリポジトリからの取得は、通常の Git 認証をそのまま使います。GitHub の shorthand 指定では、まず Git の資格情報ヘルパーを試し、失敗したら GitHub CLI の gh repo clone、最後に SSH へフォールバックします。このとき、gh auth token を実行して取得したトークンを Node.js プロセスに渡すことはありません。GitHub CLI が認証を適用した結果だけを受け取る構造です。同様に、GitHub のツリー情報を取得する API 呼び出しでは、匿名アクセス、環境変数 GITHUB_TOKEN または GH_TOKEN、gh api の順で試行します。トークンを明示的に設定するのは、プライベートリポジトリのダウンロードや更新チェックを自動化したい場合です。認証情報を CLI が直接扱わないこの設計は、監査の観点では好ましい選択です。

npx で始める、インストールと一時利用の 2 つの経路

最も基本的な使い方は npx skills add です。GitHub の owner/repo 形式、完全な URL、リポジトリ内の特定ディレクトリ、GitLab、任意の Git URL、ローカルパスをソースとして受け付けます。インストール前に中身を確認したい場合は --list フラグでスキル一覧を表示できます。インストールせずに使う場合は npx skills use です。これは指定したスキルを一時ディレクトリに展開し、生成したプロンプトだけを標準出力に出力します。--agent を指定すると、対応するエージェントを対話的に起動して、そのプロンプトを渡します。パイプで直接 claude に渡す例が README に記載されており、CI やスクリプトの中での利用を想定した設計です。

シンボリックリンク方式とコピー方式の使い分け

インストール方法は 2 種類あります。デフォルトで推奨されるのはシンボリックリンク方式で、各エージェントのディレクトリから正本へのリンクを作成します。スキルを更新すれば、全エージェントに変更が反映されるため、管理コストが低くなります。もう一方のコピー方式は、各エージェントに独立したコピーを配置します。シンボリックリンクをサポートしていない環境や、エージェントごとに異なるバージョンを固定したい場合に使います。--copy フラグで明示的に選択できます。プロジェクト単位のインストールは ./<agent>/skills/ に、グローバルは ~/<agent>/skills/ に配置されます。プロジェクト単位であれば Git にコミットしてチームで共有できますが、シンボリックリンクをコミットする際の扱いは、利用する OS や Git の設定によって挙動が異なる点に注意が必要です。

ダウンロード制限と環境変数による上書き

直接ダウンロード URL をソースに指定する場合、SKILL.md 単体か、zip、tar、tar.gz、tgz のアーカイブを受け付けます。拡張子がなくても判定されます。セキュリティ対策として、ダウンロードサイズは 10 MiB、展開後の合計は 25 MiB、ファイル数は 1000 までという制限がデフォルトで設定されています。信頼できるソースからの取得に限って、SKILLS_DOWNLOAD_MAX_BYTES、SKILLS_EXTRACT_MAX_BYTES、SKILLS_EXTRACT_MAX_FILES の環境変数で上限を引き上げられます。この制限は、悪意のあるアーカイブによるディスク消費を防ぐための最低限の防御です。ただし、アーカイブ内のシンボリックリンクやファイルパスの扱いに関する記載は README にはなく、展開時のパストラバーサル対策がどの程度行われているかは確認できません。

find と remove でスキルを検索・削除する

インストール後の管理コマンドとして、skills list がインストール済みスキルの一覧を表示します。エイリアスは ls です。skills find は対話的、またはキーワード指定でスキルを検索します。skills remove はインストール済みのスキルを削除します。これらのコマンドは名前が短く、操作体系が一貫しているため、エージェントを切り替えながら複数のスキルを管理する運用には向いています。ただし、find がどのインデックスを検索するのか、リモートのレジストリがあるのか、それともローカルのみなのかは README の記述からは明確ではありません。検索機能を本格的に使う前に、その挙動を確認する必要があります。

対応エージェントの広さと、変換の深さの不確実性

このツールの最大の売りは、70 以上のエージェントに対応している点です。しかし、エージェントごとにスキル定義の形式は大きく異なります。Claude Code の CLAUDE.md と Cursor のルールファイルでは、記述できる内容も読み込みの仕組みも違います。skills が SKILL.md をどのように各形式に変換するのか、その変換が一方向なのか、双方向なのかは README からは読み取れません。また、エージェントのバージョンアップで形式が変わった場合の追従も、この CLI の更新頻度に依存します。リポジトリの最終更新は 2026 年 8 月で、リリースも v1.5.23 まで出ています。開発は活発ですが、対応エージェントの数が多いほど、変換ロジックのメンテナンス負荷は高くなります。

既存のスキル管理手法との比較

代替手段として、各エージェントが公式に提供するプラグイン機構があります。Claude Code にはサブエージェント、Cursor にはルールファイルのインポート機能があります。これらはエージェントごとに最適化されていますが、共通化するためには各形式で同じ内容を管理することになります。skills はその逆で、共通形式を一箇所に置き、各エージェントへの展開を自動化します。もう一つの比較対象は、Git サブモジュールや dotfiles 管理ツールです。これらはファイルの同期はできますが、エージェント固有の形式への変換は行いません。skills のアプローチは、形式変換を含めた点で一歩進んでいますが、その変換ロジックに依存するというリスクも同時に背負います。

編集部の結論

採用を検討するなら、まず自分の使うエージェントが対応リストに含まれているか、そしてスキルを共有するチームが Git 認証をどう設定しているかを確認してください。この CLI は GitHub の認証情報を Node.js プロセスに渡さない設計で、セキュリティ面での配慮が明確です。一方で、シンボリックリンクを前提とした更新管理は、Windows 環境やファイルを直接編集する運用には向いていません。対応エージェントが 70 以上ある点は利点ですが、その分だけ各エージェントの設定形式の差異を吸収する部分がブラックボックスになりがちです。スキルを一箇所で管理し、複数エージェントに同じ指示を配りたい個人開発者や小規模チームには有力な選択肢です。大規模な組織でエージェントごとに異なる運用ルールを持つ場合は、コピー方式を選ぶか、Git サブモジュールなど別の管理手段と比較する価値があります。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes