プラグインカタログ

プラグインカタログは、人の目で審査された Hermes プラグインをまとめたディレクトリです。 コマンド1つ、名前を指定するだけで導入できます。

hermes plugins install <name>

見て選びたいときは /docs/plugins を開いてください。 カテゴリ（メモリ、デスクトップ、プラットフォーム、Web とブラウザ、ツール、音声、自動化、 モデル）ごとに棚が分かれていて、検索、ティア絞り込み（公式 / 認証済み / コミュニティ）、機能チップ、 そして各項目のコピーできるインストールコマンドが並びます。

カード（クリックできます）ごとに専用ページ /docs/plugins/<name> もあります。 説明の全文と注意書き、固定されたコミット、ツール・フック・環境変数、デスクトップ用の インストールボタンと CLI コマンド、スクリーンショット（ある場合）と審査時のコミットの README、 さらに この作者の他の作品 の棚が載ります。作者ごとのページ /docs/plugins/by/<maintainer> には、 その人がカタログで保守しているものがすべて並びます。どちらも同じカタログファイルからビルド時に 生成されるので、ページが変わるのは PR がマージされたときだけです。

カタログは既存のプラグインの仕組みを置き換えるものではなく、補うものです。 カタログから入れたものも中身はふつうのプラグインで、カタログは見つけやすさと審査の層を その上に足しているだけです。

デスクトップのオンボーディング中には、セットアップガイドが承認カードを通じてカタログのプラグインやスキルを 勧めることもあります。各行は Install をクリックしたときにだけ default プロファイルに入り、 このページで説明しているのと同じ審査済みのコミットが使われます。

項目の中身

カタログの各項目は、hermes-agent リポジトリの plugin-catalog/ ディレクトリに置かれた小さな YAML ファイルで、次の内容を宣言します。

信頼の考え方

カタログは、自分が何を入れようとしているのかがはっきり分かるように作られています。

• 人がマージして初めて載る。 どの項目も（固定値の更新も）保守担当がレビューした

プルリクエストを通って入ります。自動で入るものはありません。

• SHA での正確な固定。 項目が固定するのはブランチではなく特定のコミットです。プラグインの

作者がリポジトリに新しいコードを push しても、カタログが入れるものは変わりません。 固定を更新するには、もう一度レビュー付きの PR が要ります。

• 載せるときに走査し、入れるときは信頼する。 受け入れ時の CI は、インストーラーが走らせるのと

同じセキュリティスキャナーを実行します（hermes plugins validate には security scan の チェックが含まれます）。dangerous と判定されればその項目は落ち、caution の指摘は 審査する人に一覧で示されます。審査した人がそれを見ているので、固定された SHA をそのまま チェックアウトするカタログ経由のインストールは caution について改めて尋ねません。 dangerous は変わらず止めますし、生の URL から入れたものや別のリビジョンで入れたものには 通常どおり確認が出ます。

• デスクトップのプラグインはアプリと同じ権限で動く。審査が境界線です。

プラグインの desktop/plugin.js はデスクトップアプリ自身の中、アプリのコードと同じ領域で 評価されます。サンドボックスは無く、アプリにできることは何でもできます（ゲートウェイの RPC、 window.hermesDesktop ブリッジの全機能、他のプラグインの保存領域）。守ってくれるのは 上に書いた信頼の考え方です。人が固定されたコミットそのものを読み、インストールされるのは そのコミットである、という点。加えて仕掛けが2つあります。受け入れ時の desktop surface lint がプラグイン SDK の外へ出る分かりやすい手口を拒みます（組み込みのプロトタイプへの パッチ、eval、@hermes/plugin-sdk/react 以外の読み込み、リモートのスクリプトの取り込み）。 そしてアプリのローダーが読み込み時にも SDK 以外の import をもう一度拒みます。lint は <script を含む正規表現 （リテラル、または .replace()/.split()/.match() にそのまま渡すか .test()/.exec() で使う new RegExp(...) のパターン文字列）を、注入ではなく本来の役目どおりの無害化処理として扱います。 一方、DOM に書き込まれる <script の文字列は、new RegExp(...).source から組み立てたものも含めて、 引き続き不合格になります。この lint は 審査の助けであって保証ではないと考えてください。デスクトップ側にも Python 側と同じ目を 向けてください。

• Hermes を実行時に書き換えない。 載っているプラグインは、公開された接点（フック、

ミドルウェア、プロバイダーのプロファイル、デスクトップ SDK のスロット）を通して Hermes を拡張し、 コアの関数・メソッド・デスクトップの UI をその場で置き換えることはしません。2 つのプラグインが同じ 継ぎ目を書き換えると互いに壊し合い、コアのリリース1つで両方が壊れることもあるからです。審査の no core override チェックは、Hermes のモジュール・クラス・その表を実行時に差し替える Python を拒み、 desktop surface の lint は、アプリ自身のマークアップを探してコアの UI の見た目を変えたり、隠したり、 クリックしたり、書き換えたりする desktop/plugin.js のコードを拒みます。

• 機能の宣言。 各項目は、そのプラグインが提供するツール・フック・ミドルウェアと、必要な

環境変数（API キーなど）を最初に明示します。入れる前に影響範囲を判断できます。

• 削除リスト。 カタログから取り下げられたプラグイン（たとえばセキュリティ上の問題が

あった場合）は、理由と日付を添えて plugin-catalog/removed.yaml に載ります。照合は名前か リポジトリの同一性で行われ、同じリポジトリの git@、ssh://、http://、www. といった 書き方はすべて一致します。インストーラーは削除リストにあるものを入れませんし、入れた*あとで* リストに載ったプラグインは更新が止まり、有効にできなくなり、読み込み時にも拒まれます （hermes plugins remove <name> で外すか、承知の上で使い続けるなら --allow-removed を付けて 入れ直します）。

• 入れることと有効にすることは別。 カタログのプラグインを入れるとディスクに置かれますが、

他のプラグインと同じで、読み込まれるには有効にする操作が別に要ります。 プラグイン → 有効化と無効化を参照してください。

カタログから入れる

# Install a reviewed catalog entry by name (checks out the pinned SHA)
hermes plugins install <name>

# Then enable it, as with any plugin
hermes plugins enable <name>

インストール時の確認画面には、クローンが始まる前に、その項目の機能のまとめ（宣言された ツール、フック、必要な環境変数）が表示されます。端末ではそのあと「Enable now?」と聞かれるので、 「はい」と答えれば上の 2 つのコマンドが 1 回で済みます（スクリプトでは --enable / --no-enable で この問いに答えられます）。

カタログ上の名前と、プラグイン自身のマニフェスト上の名前は違うことがあります。そのあとの コマンド（enable、disable、show、capabilities、update、remove）は、どちらの名前でも 受け付けます。カタログ上の名前は、Hermes が項目をクローンしたときに書いたインストール記録を通して 解決されます。プラグイン自身のリポにあるファイルを通すことはありません。たとえば touchdesigner の項目（twozero の MCP サーバーと touchdesigner-mcp スキルをまとめた 可搬型の Agent Plugins v1 パッケージ）は td として入ります。生成される MCP のツール名が プロバイダーの関数名の長さ制限に収まるよう、短くしてあります。

hermes plugins install touchdesigner
hermes plugins enable touchdesigner   # same as: hermes plugins enable td

Desktop アプリでは、エージェント側と Desktop 側（desktop/plugin.js）の両方を持つパッケージは 1 行にまとまり、それぞれの側に 1 つずつ切り替えスイッチが付きます。パッケージをオンにすると （インストール画面からインストールするとオンになります。行の Agent スイッチでもオンにできます）、 Desktop 側も一緒にオンになります。ただし、その側を自分でオフにしていた場合は別です。オフにする操作は 側ごとのままです。Desktop 側はすべてのプロファイルで共有されているからです。

可搬型のパッケージは stdio の MCP サーバーを同梱することもできます。snyk の項目は Snyk CLI（npx -y snyk@<version> mcp）を固定し、snyk-security-scan スキルを同梱しているので、 1回入れるだけで Hermes がコード・依存関係・コンテナ・IaC の走査と、その使い方の手順まで 手に入れます。この項目はカタログ上の名前とマニフェストの名前が一致します。

hermes plugins install snyk
hermes plugins enable snyk

カタログから入れたものを更新する

hermes plugins update <name> は、カタログから入れたものに対して git pull を走らせることは ありません。手元の固定値と現在のカタログの固定値を比べて、カタログ側が（レビュー付きの PR で） 動いていたら、新しい SHA を準備して依存関係を検証してから、それを公開します。有効・無効の状態はそのまま引き継がれ、 プラグインのリポジトリが管理していないファイル（.example から作った config.yaml、データ ファイル、.env）も残ります。 こうした管理外のファイルの中にシンボリックリンクがあっても、新しいコードの側へたどることはありません。 更新は公開の手前で止まってそのリンクの名前を示すので、それぞれを通常のファイルに置き換えてください。 依存関係やキャッシュのディレクトリ（.venv/、venv/、node_modules/、ツールのキャッシュ）は、 リンクも含めて一切引き継がれません。更新後のプラグインが依存関係を作り直します。 モノレポやサブディレクトリから入れたものは手元に Git のチェックアウトを持たないので、 更新では、新しいリビジョンに含まれないユーザー状態のファイルを残します。プラグインのコードと 動きを決める部分はリビジョンの持ち物なので、古いインストールから復活させることはありません。 対象はソースファイル（Python、.mjs/.cjs/.jsx/.tsx を含む JavaScript/TypeScript、 シェル、Ruby、Perl、PHP）、最上位の dashboard/、desktop/、skills/、 sidecar/、node_modules/ ディレクトリ、プラグインのマニフェスト、mcp.json、 依存関係のメタデータ（pyproject.toml、package.json、ロックファイル）です。ユーザー状態の パスが新しいツリーのファイルやディレクトリの配置とぶつかる場合、更新は公開の手前で止まるので、 入っているコピーも、ユーザーのデータもそのまま残ります。 *管理下の*ファイルに加えた変更は新しいコードへは持ち越されません。 写しが ~/.hermes/plugins-backup/<name>-<sha>/ に保存され、更新時に警告が出ます。 新しい固定値でプラグインのマニフェスト名が変わっていた場合は、古いディレクトリが削除され、 有効フラグは新しい名前へ移ります。hermes plugins list はカタログから入れたものを catalog:<tier>@<sha> と表示するので、出どころがひと目で分かります。

有効なプラグインについては、新しいコードで入れ替える前に PM が依存関係を検証します。バージョン、走査、 依存関係、公開のどこかで失敗した場合は、動いているコードと依存関係の選択がそのまま残ります。 無効にしてあるプラグインは無効のままです。 出どころはインストーラーが ~/.hermes/plugins/.install-metadata.json に記録します。 プラグイン自身のツリーの外なので、審査済みのカタログ経由に見せかけるファイルをリポジトリ側が 同梱することはできません。（プラグインのディレクトリにある .hermes-catalog.json は便宜上の 写しにすぎません。）カタログの項目を --ref <sha> を付けて入れた場合は、実際にチェックアウト した SHA が記録されるので、list、デスクトップのプラグインタブ、update のいずれもが 「審査された固定値から外れている」と報告します。 カスタムの Git プラグインは、記録された Git やフィードの更新方針を保ちつつ、 同じ PM の検証と公開の流れを通ります。

カタログに無い名前

カタログの項目でない名前をそのまま渡すとエラーになります。審査を経ていない名前の索引が 別にある、ということはありません。そういうプラグインは owner/repo か Git の URL で入れるか （独自の入手元。下記参照）、カタログへ応募してください。

最新の取り込み

ドキュメントのビルドは、カタログを1つの JSON 文書として公開します （https://hermes-agent.nousresearch.com/docs/api/plugin-catalog.json）。 search/install/update は6時間に1回までの頻度でこれを取得し、~/.hermes/cache/ に キャッシュします。そのため、新しい項目や削除は Hermes を更新しなくても手元に届きます。 オフラインのときはキャッシュした写しが24時間まで使われ、その後は手元のチェックアウトに 同梱された写しが引き継ぎます（取得の失敗は1分間覚えられるので、plugins list と ダッシュボードのプラグインページで発生する接続待ちは、入れたプラグインの数だけではなく 最大でも1回分です）。キャッシュした文書と手元のチェックアウトで項目の固定値が食い違う場合は、 新しいほうが勝ちます。文書が公開されたあとにカタログがコミットされたチェックアウト （hermes update した直後など）は、キャッシュにある古いほうではなく自分の固定値を入れます。 ツリー内のリストと公開リストの削除は、キャッシュの新しさに関わらず、常にどちらも適用されます。

独自の git URL は別物

hermes plugins install <git-url> はどのリポジトリに対しても従来どおり使えますが、 カタログは完全に迂回されます。

• 審査なし — 審査された固定値ではなく、ブランチの先端にあるものがそのまま入ります。
• 警告の帯が表示され、そのコードが未検証であることを知らせます。
• 削除リストは変わらず参照されます（問題が分かっているリポジトリは URL でも拒まれます）。

git URL の経路は自分のプラグインや、すでに信頼しているリポジトリに使ってください。 見つけるための場所としてはカタログを使ってください。

カタログへプラグインを応募する

応募は、plugin-catalog/<name>.yaml を1つ追加するプルリクエストです。 完全なガイドラインは プラグインカタログへの応募 にあります。 応募前に確認すること、PR とレビューの進み方、受け入れの規則のすべて、 固定値の更新・掲載の取り下げ・削除の扱いが書かれています。このページは plugin-catalog の README にある正式な規則を写したものです。

要点だけ言うと、載っているプラグインは、持ち主が応募したもの（または保守担当が審査した一斉調査で 追加したもの）で、公開リポジトリにあり、正確なコミットに固定され、カタログの CI で hermes plugins validate を通り、自分で自分を更新しません。そして Hermes を拡張するのは公開された フックとデスクトップ SDK を通してだけで、コアのコードやデスクトップの UI を実行時に書き換えることはしません。

関連

• プラグイン — プラグインの仕組みそのもの。マニフェストの形式、有効化、

設定

• 組み込みプラグイン — Hermes に同梱されているプラグイン
• Hermes プラグインを作る — 自分で書く
• プラグインカタログのページ — 一覧を見て選ぶ
• プラグインカタログへの応募 — 受け入れの規則と応募のガイド