Claude Codeで動くプロンプト集を作ったとして、それをCursorでも使いたくなったとき、ファイルをコピーして手作業で書き直した経験はないでしょうか。あるいは、チームの半分がCopilotを使い、残り半分がCodexを使っている状況で、エージェント定義を二重管理しているプロジェクトを見かけたことはないでしょうか。wshobson/agents は、そういった状況に対してひとつの答えを出しているリポジトリです。単なるプロンプト集ではなく、「単一のMarkdownソースから複数のAIハーネスにネイティブなアーティファクトを生成する」という設計思想が全体を貫いています。紹介と設計の両面から深く見ていきます。
どんなリポジトリか
一言で表すなら、「マルチハーネス対応のエージェント型プラグインマーケットプレイス」です。Claude Codeをソース・オブ・トゥルースとして、OpenAI Codex CLI、Cursor、OpenCode、Google Antigravity CLI、GitHub Copilotの合計6つのハーネスへ、それぞれのネイティブ形式でアーティファクトを配信します。
収録されているのは、93のプラグイン、202のエージェント、181のスキル、105のコマンド、そして16のオーケストレーターです。カバーする領域はPython開発、Django、FastAPI、インフラ、セキュリティ、ML、ドキュメント生成、SEOにまで及びます。インストールはClaude Code側なら /plugin install python-development の一行で済み、Codexなら npx codex-marketplace add wshobson/agents で始められます。
想定ユーザーは、複数のAI開発ツールを横断して使うエンジニアや、チームで統一したエージェント定義を管理したいリードです。ハーネスを選ばない設計のため、自分の環境に合わせた取り込み方ができます。
設計でここが上手い
ソース分離とアーティファクト生成の徹底
プラグインのソースは plugins/ 以下にのみ存在し、ハーネスごとの生成物（.codex/、.opencode/、.antigravity/ など）はgitignoreされています。手で生成物を編集することは禁止されており、変更は必ずソースに入れてから make generate-all で再生成します。これはCIでもドリフト検出として自動チェックされるため、「ソースと生成物がズレる」状態が混入しにくい構造になっています。
この設計の利点は、ハーネスが増えたときに既存のプラグインを書き直さずに済む点です。新しいアダプターを足すだけでよく、既存の202エージェントが即座に新ハーネスに対応します。
オンデマンドなコンテキスト管理
プラグインをインストールするとき、マーケットプレイス全体のコンテキストがロードされるわけではありません。「インストールしたプラグインのコンポーネントだけがコンテキストに読み込まれる」という設計が明記されています。たとえば python-development をインストールした場合、3つのエージェント、1つのコマンド、16のスキルだけが対象で、残り90以上のプラグインは無関係です。
スキルはさらに「プログレッシブ・ディスクロージャー」という仕組みを採っており、アクティベートされたときだけ詳細な内容がロードされます。Codex向けには8KBのスキル上限が設けられており、超過する詳細は references/details.md に分離されます。93プラグイン全部を入れてもトークン消費が膨らみにくい構造です。
モデル階層による役割分担
エージェントにはTier 0〜4のモデル階層が定義されています。アーキテクチャレビューやセキュリティ監査にはOpus、ドキュメント生成やテストにはSonnet、デプロイや軽量タスクにはHaikuを割り当てるという分担で、コストと品質のバランスを設計レベルで制御しています。Tier 2は inherit となっており、ユーザーが選んだモデルをそのまま引き継ぐ柔軟性も持たせています。
三層評価フレームワーク
plugin-eval という組み込みの評価ツールが用意されており、静的解析（2秒以下、無料）、LLMジャッジ（4次元の意味的評価、約30秒）、モンテカルロ法（50〜100回の統計的信頼性検証、2〜5分）の三層で品質を測定できます。プラグインを書いて終わりではなく、品質を数値化して認証する仕組みが同梱されているのは珍しい工夫です。
こういう人に向くかも
Claude Codeをメインで使いながら、チームの別メンバーがCursorやCopilotを使っているような状況で、エージェント定義を統一管理したい人には特に合います。「ハーネスが違うから同じプロンプトを使えない」という摩擦を減らしたいチームです。
逆に、Claude Code一本で完結していて他ハーネスを使う予定がない場合は、マルチハーネス対応の恩恵よりも管理の複雑さが先に目に入るかもしれません。93プラグインという規模感は、個人の小規模な開発より、ある程度の広さで仕事をするエンジニアやチームに向いています。また、make generate-all や uv・ruff・ty といったツールチェーンを前提にしているため、Pythonエコシステムに慣れていることが導入のスムーズさに直結します。
設計の良し悪しをどこで見るか
評価の軸として、特に気になった点を以下で整理します。
単一機能の純粋さ
このリポジトリは「マルチハーネス対応のプラグイン配信基盤」というひとつの機能に集中しているように見えますが、実際には93プラグイン×6ハーネスという組み合わせの数が膨大です。単一プラグインを見れば確かに分離されていますが、リポジトリ全体の複雑さはかなり高い水準にあります。新しく参加する人がコントリビュートしようとしたとき、docs/authoring.md や docs/harnesses.md を読み込むまでの学習コストは相応に大きいでしょう。
ドキュメントの深度
docs/ 以下に8つのMarkdownファイルが整備されており、プラグイン一覧、エージェント一覧、ハーネスごとの詳細、品質評価フレームワーク、ラウンドトリップ検証レシピまでカバーされています。CLAUDE.md が150行以内に収める方針を明示しているのも好印象で、「コンテキストファイルを読みすぎない」という意識が設計に組み込まれています。ただ、初見でドキュメントの全体像をつかむまでには少し時間がかかります。
想定外の使われ方への備え
セキュリティ面では、外部の git-subdir エントリ（HOL Guard、Pensyve）をコミットハッシュで固定しており、承認なしに動作が変わらないようになっています。HOL Guardのインストールにはユーザー承認が必要で、デフォルトパスでGuard Cloudを要求しない設計も明記されています。外部依存の扱いとしては丁寧な部類です。
メンテナンスの継続性
39,000以上のスターは参考値として、CI（.github/workflows/validate.yml）が全PRでバリデーションとスモークテストを自動実行する構造は、コントリビューションを受け入れながら品質を保つための仕組みとして機能しています。ただし、202エージェントと6ハーネスを同時にメンテナンスし続けるコストは小さくなく、長期的にどこまでアクティブに更新されるかは使う側も意識しておくべき点です。
自分が書くなら、どこを変えるか
気になる点として、プラグイン間の依存関係の管理が挙げられます。現在の設計では各プラグインは独立した単位として扱われていますが、実務では「セキュリティプラグインとPythonプラグインを同時に使うとき、スキルが重複しないか」という問いが出てきます。プログレッシブ・ディスクロージャーでコンテキスト消費を抑えているとはいえ、複数プラグインを組み合わせたときの挙動を検証する仕組みが plugin-eval に組み込まれていると、より安心して複数インストールに踏み込めるかなと思います。
もうひとつは、ハーネスごとの機能差分の可視化です。docs/harnesses.md にケイパビリティマトリクスが存在するとのことですが、「Antigravity CLIではこのスキルが使えない」という情報がプラグイン単位のカタログ（docs/plugins.md）側からも参照できると、選定の判断がしやすくなります。プラグインを選んでからハーネスの制約に気づくより、先に分かる方が実用的です。
導入を検討するときのチェック観点
- 自分が使っているAIハーネス（Claude Code、Cursor、Codex、OpenCode、Antigravityなど）がリポジトリのサポート対象に含まれているか
uv・make・ruffといったPythonツールチェーンを導入できる環境か- 93プラグインのうち、実際に使いそうなプラグインが
docs/plugins.mdのカタログに存在するか - チームで共有する場合、ハーネスの違いを
make generate-allで吸収する運用フローを組み込めるか - 外部依存（Pensyve、HOL Guard）の固定コミットを定期的に追従・審査できるか
- CIがドリフトを検出したとき、生成物を再ビルドして対応できる担当者がいるか
plugin-evalの三層評価を使って、社内で追加するプラグインの品質基準を設けるつもりがあるか
運用の現実と向き不向きの分かれ目
wshobson/agents が提供しているのは、「ハーネスを選ばないエージェント資産の統一管理」というアイデアの実装例です。単一ソースから複数ハーネスへ変換するアダプター構造は、チームの環境が混在しているほど効果を発揮します。ただし、その恩恵を受けるには make generate-all を開発フローに組み込み、CIのドリフト検出を維持する運用が前提になります。個人で使うには規模が大きく、チームで使うには導入の初期投資が必要です。どちらが自分の状況に合うかを確かめてから入るのが、このリポジトリと長く付き合うコツかなと思います。
