キュレーター

キュレーターは、エージェントが作ったスキルを裏側で手入れする仕組みです。各スキルが何回見られ、使われ、手を入れられたかを記録し、長く使われていないスキルを active → stale → archived と移し、ときどき短い補助モデルのレビューを走らせて、統合の提案やずれの修正を行います。

これがあるのは、自己改善のループで作られたスキルが際限なく積み上がらないようにするためです。エージェントが未知の問題を解いてスキルとして保存するたび、それは ~/.hermes/skills/ に置かれます。手入れをしないと、狭い範囲の似たようなスキルが何十本もたまり、一覧を汚してトークンを無駄にします。

既定では、キュレーターはエージェントが作ったスキルだけを扱います。curator.prune_builtins: true にすると、使われていない同梱の組み込みスキル（リポジトリに同梱されているもの）も archive_after_days のあいだ使われなければ書庫に入れられます。これを任意設定にしているのは、同梱のスキルが黙って skills_list から消えると、インストールが壊れたと勘違いしやすいからです。ハブから入れたスキル（agentskills.io 由来）は常に対象外です。キュレーターは自動で削除することもありません。最悪でも ~/.hermes/skills/.archive/ へ書庫入れするだけで、元に戻せます。

issue #7816 に対応しています。

動くタイミング

キュレーターを動かすのは cron ではなく、無操作の確認です。CLI のセッション開始時、ゲートウェイの定期処理の途中（同じ端末のデスクトップはゲートウェイにつなぐので、これでまかなわれます）、そして hermes serve の保守タイマーで、Hermes は次の2点を確認します。

1. 前回のキュレーター実行から十分な時間が経っているか（interval_hours、既定は 7日）。
2. エージェントが十分に休んでいるか（min_idle_hours、既定は 2時間）。

hermes serve / hermes dashboard のバックエンド（たとえばデスクトップのリモート接続）は、cron とは別に、既存の1時間ごとの保守タイマーを共有します（最初の確認は90秒後）。無操作の長さは、プロセスの起動時刻と、同じプロファイルでの直近のチャットの動きから測り、セッションが閉じられたり回収されたりしたあともその時刻を保持します。そのプロファイルでターンが動いているあいだはキュレーターを飛ばします。つながっているだけで動いていないウィンドウが保守を妨げることはありません。同じプロファイル向けのメッセージングゲートウェイが動いている場合は、そちらがこの雑務を受け持ちます。

タイマーが面倒を見るのは、そのバックエンドのプロファイルです。実行中の保守はワーカースレッドで動くので、バックエンドを閉じてもその処理は協調的に中断されません。同じプロファイルに対して独立した serve プロセスを複数立ち上げると、キュレーターの間隔確認が競合することはあります。

両方を満たしていれば、AIAgent のバックグラウンドのフォークを立ち上げます。メモリやスキルの自己改善のうながしと同じやり方です。フォークは自分のプロンプトキャッシュで動き、進行中の会話には一切触れません。

1回の実行は2段階に分かれます。

1. 自動の状態遷移（決まった手順どおり、LLM は使いません）。stale_after_days（14日）使われていないスキルは stale になり、archive_after_days（30日）使われていないスキルは ~/.hermes/skills/.archive/ へ移ります。これが常時動く整理の動きで、キュレーターが有効なときは必ず走り、補助モデルの費用はかかりません。

• 固定されたスキルと、cron のジョブから参照されているスキル（停止中・無効のジョブも含む）は、まるごと飛ばされます。自動遷移については固定と同じ扱いなので、間隔の長いジョブや止めてあるジョブの足元からスキルが書庫入りすることはありません。統合の際には、傘にまとめるときに cron のスキル参照も書き換えます。
• 一度も使われていないスキル（use_count == 0）には猶予の下限があります。少なくとも stale_after_days ぶんの古さになるまでは書庫入りしません。使用回数ゼロは証拠が無いということであって、捨ててよい証拠ではありません。

1. LLM による統合（補助モデルの1回の処理で、繰り返しの上限は高めです。ひととおりの整理には通常 50〜100 回の API 呼び出しがかかります）。これは既定でオフです。curator.consolidate: true にすると、フォークしたエージェントがエージェント製のスキルを見渡し、skill_view でどれでも読み、スキルごとに、そのまま残すか、（skill_manage で）手を入れるか、重なっているものをクラス単位の傘にまとめるか、（absorbed_into の移行先を指定した skill_manage action=delete で）書庫入りさせるかを決めます。この処理に終点はありません。渡される候補の一覧には、実際に読み書きできるスキルだけが入ります。同梱の組み込みスキル（prune_builtins: true にしていても同じで、この設定が効くのは決まった手順の書庫入れだけです）と、skills.disabled にあるスキル（skill_view が拒みます）は候補に出ないので、拒まれる読み書きでツールの予算を使い切ることはありません。統合はスキルをひとまとまりのパッケージとして扱います。スキルが references/、templates/、scripts/、assets/ を持っていたり、それらへの相対リンクを持っていたりする場合、キュレーターは、そのスキルを単体のまま残すか、必要な補助ファイルを移してパスを書き換えるか、パッケージ全体をそのまま書庫入りさせるかのいずれかを選ばなければなりません。SKILL.md だけを別のスキルの references/ にまとめて押し込む、というやり方は取りません。

固定されたスキルは、キュレーターの自動遷移からも、エージェント自身の skill_manage ツールからも手出しできません。下のスキルを固定するを参照してください。

設定

設定はすべて config.yaml の curator: 以下にあります（.env ではありません。秘密の情報ではないからです）。既定値は次のとおりです。

curator:
  enabled: true
  interval_hours: 168          # 7 days
  min_idle_hours: 2
  stale_after_days: 14
  archive_after_days: 30
  consolidate: false           # LLM umbrella-building pass — opt-in (prune-only by default)
  prune_builtins: false        # opt in to archiving unused bundled built-in skills too (hub skills always exempt)

まるごと止めるには curator.enabled: false にします。常時の整理は残したまま LLM の統合も使いたいときは curator.consolidate: true にします。

レビューを安い補助モデルで走らせる

キュレーターの LLM レビューは、ふつうの補助タスクの枠 — auxiliary.curator — です。画像認識、圧縮、セッション検索などと並びます。「Auto」は「メインのチャットモデルを使う」という意味で、この枠を上書きすると、レビューだけ特定のプロバイダーとモデルに固定できます。

いちばん簡単な方法 — hermes model:

hermes model                   # → "Auxiliary models — side-task routing"
                               # → pick "Curator" → pick provider → pick model

同じ選択画面は、Web ダッシュボードの Models タブにもあります。

config.yaml を直接書く場合（同じ意味）:

auxiliary:
  curator:
    provider: openrouter
    model: google/gemini-3-flash-preview
    timeout: 600               # generous — reviews can take several minutes

provider: auto（既定）のままにすると、レビューはメインのチャットモデルを通ります。他の補助タスクと同じ動きです。

CLI

hermes curator status         # last run, counts, pinned list, LRU top 5
hermes curator run            # trigger a run now (blocks until done). Prune-only unless curator.consolidate: true
hermes curator run --consolidate # force the LLM consolidation pass on for this run, overriding the config default
hermes curator run --background  # fire-and-forget: start the run in a background thread
hermes curator run --dry-run  # preview only — report without any mutations
hermes curator backup         # take a manual snapshot of ~/.hermes/skills/
hermes curator rollback       # restore from the newest snapshot
hermes curator rollback --list     # list available snapshots
hermes curator rollback --id <ts>  # restore a specific snapshot
hermes curator rollback -y         # skip the confirmation prompt
hermes curator pause          # stop runs until resumed
hermes curator resume
hermes curator pin <skill>    # never auto-transition this skill
hermes curator unpin <skill>
hermes curator adopt <skill>    # hand an unmanaged skill to the curator
hermes curator adopt --all-unmanaged   # hand over every unmanaged skill
hermes curator list-unmanaged   # itemize skills with no provenance marker
hermes curator restore <skill>  # move an archived skill back to active
hermes curator list-archived    # list skills currently in ~/.hermes/skills/.archive/
hermes curator archive <skill>  # manually archive a single skill now
hermes curator prune [--days N] # bulk-archive agent-created skills idle >= N days (default: `archive_after_days`, 30)
hermes curator ledger           # list the per-mutation audit ledger (all actors)
hermes curator ledger --skill <name> --limit 50  # filter/paginate ledger entries
hermes curator rollback <entry-id>  # undo a single mutation from the ledger
hermes curator purge [--days N] [--dry-run]  # delete archived skills older than the TTL (explicit only)

バックアップと巻き戻し

統合の処理（consolidate: true。スキルの中身をその場で書き換える唯一の処理です）の前に、Hermes は ~/.hermes/skills/ の tar.gz スナップショットを ~/.hermes/skills/.curator_backups/<utc-iso>/skills.tar.gz に取ります。スナップショットに入るのは現役のスキルのツリーだけです。.archive/、監査台帳、.hub/、そしてバックアップ自体は決して巻き込まれませんし、巻き戻しがそれらを戻すこともありません（古い写しに戻すと、書庫入りしたスキルや台帳の記録が失われるからです）。触ってほしくなかったものが書庫入りしたり統合されたりしたときは、コマンド1つで実行まるごとを取り消せます。

hermes curator rollback        # restore newest snapshot (with confirmation)
hermes curator rollback -y     # skip the prompt
hermes curator rollback --list # see all snapshots with reason + size

巻き戻し自体も元に戻せます。スキルのツリーを置き換える前に、Hermes は pre-rollback to <target-id> という印を付けたスナップショットをもう1つ取ります。巻き戻しを間違えたときは、--id でそちらへ進めば取り消せます。

hermes curator backup --reason "before-refactor" で、いつでも手動のスナップショットを取れます。--reason に書いた文字列はスナップショットの manifest.json に入り、--list で表示されます。

既定の整理だけの処理はスナップショットを取りません。ディレクトリをまるごと .archive/ へ移すだけで、それ自体が取り消しの手段になっていますし（hermes curator restore）、変更はすべて下の台帳に残るからです。ディスクの使用量を抑えるため、スナップショットは処理のたびに curator.backup.keep（既定は2）まで減らされます。

curator:
  backup:
    enabled: true
    keep: 2

自動のスナップショットを止めるには curator.backup.enabled: false にします。バックアップを止めている状態で手動の hermes curator backup を使いたい場合は、先に enabled: true に戻す必要があります。このフラグは両方の経路を対称に制御するので、中身を変える実行の前のスナップショットをうっかり飛ばしてしまうことはありません。

hermes curator status は、最後に使われてから最も時間が経っているスキル5件も表示します。次に古くなりそうなものをすばやく把握できます。

同じサブコマンドは、動いているセッション（CLI でもゲートウェイのプラットフォームでも）の中で /curator スラッシュコマンドとしても使えます。

監査台帳と1件だけの巻き戻し

実行まるごとのスナップショットは「直前のキュレーターの処理を全部取り消す」に答えるものですが、*誰が何を変えたのか*を知って、1件だけ取り消したいこともあります。スキルへの変更はすべて — キュレーターの自動遷移、エージェントの skill_manage 呼び出し、自分で打った CLI の archive/restore/purge — ~/.hermes/skills/.curator_ledger.jsonl にある追記専用の JSONL 台帳に1件ずつ記録されます。

• actor — curator（バックグラウンドのレビューのフォークと自動遷移）、agent（前面のエージェントのツール呼び出し）、user（CLI のコマンド）
• action — create、edit、patch、delete、write_file、remove_file、archive、restore、purge、rollback
• evidence — 削除の意図（統合なら absorbed_into、整理なら空、そして元に戻せる書庫入れの経路が処理したかどうか）、分かる場合はきっかけになったセッションの id
• before/after — ファイルごとの {path, sha256} の一覧。ファイルの中身は内容で名前を付けて（ハッシュで重複を除いて）~/.hermes/.curator_backups/blobs/ に保存されるので、同じ変わらないファイルに触れる記録が100件あっても、実体は1つで済みます。

hermes curator ledger                  # newest 20 entries
hermes curator ledger --skill my-skill --limit 50
hermes curator rollback <entry-id>     # restore that one mutation's before-state

1件だけの巻き戻しは、その変更が触れたファイルだけを（作られたファイルは消して）保存庫から戻します。スキルのツリーの他の部分は動きません。ツリーまるごとの巻き戻しと同じく、まず現在の状態を安全用の台帳の記録として取り、失敗したら止まります。安全用の記録が書けなければ、何も変更しません。前面での削除も台帳に残るので、hermes curator rollback <entry-id> は完全に消したスキルをよみがえらせることもできます。

台帳は記録であって関門ではありません。記録の書き込みに失敗しても、変更そのものは通ります。止めたいときは次のようにします。

skills:
  ledger: false

このファイルには大きさの上限もあります。skills.ledger_max_bytes（既定は 5 MB）を超えると、次の変更はまず、変わっていないファイルの重複除去を通してファイルを書き直し（hermes curator ledger --compact がやることそのものです）、それでも本当に中身の違う記録が上限を超えるなら、形に関わらず古いものから落とします。最新の記録は必ず残り、残った末尾の行が書き直されたり解析されたりすることはなく（そこにある壊れた行はそのまま残ります）、この掃除で、どこからも参照されなくなって1時間以上経った実体が解放されます（参照の無い新しい実体は、別のプロセスがまだ記録していない取得のものかもしれないからです）。0 にすると、台帳はずっと追記専用のままになります。

skills:
  ledger_max_bytes: 5242880   # 0 = never auto-maintain

書庫の保存期間と削除

書庫入りしたスキルは、既定ではずっと残ります。~/.hermes/skills/.archive/ に上限を設けたいときは、保存期間を決めて明示的に削除してください。削除が自動で走ることはありませんし、削除されるスキルはどれも先に（実体ごと）台帳へ記録されるので、削除のあとにも監査できて元に戻せる跡が残ります。

curator:
  archive_ttl_days: 180   # 0 (default) = never purge

hermes curator purge --dry-run   # preview what would be deleted
hermes curator purge             # delete archives older than the TTL (with confirmation)
hermes curator purge --days 90   # one-off TTL override

「エージェント製」の意味

キュレーターが扱うのは、~/.hermes/skills/.usage.json で明示的に エージェント製と印が付いたスキルだけです。次のすべてを満たすと その対象になります。

1. 名前が ~/.hermes/skills/.bundled_manifest（リポジトリに同梱されたスキル）に無いこと。
2. 名前が ~/.hermes/skills/.hub/lock.json（ハブから入れたスキル）に無いこと。
3. .usage.json の記録に "created_by": "agent" か "agent_created": true があること。

いまのところ、この印を付けるのはバックグラウンドの自己改善レビューのフォークだけです。 定期的なレビュー（エージェントのターンおよそ10回ごと）の中で新しい傘のスキルを作ったときに付きます。 このバックグラウンドのフォークは書き込みの出どころが "background_review" として動き （tools/skill_provenance.py 経由）、skill_manage の中で mark_agent_created() が呼ばれるのはこの経路だけです。

会話の中で前面のエージェントが skill_manage(action="create") で作ったスキル （/learn を含みます）は、エージェント製の印が付きません。created_by: learn として 記録され、学びの足あとにはすぐ出てきますが、 キュレーターの対象にはなりません。利用者の指示で作られたものと見なされ、 キュレーターは意図的に手を出しません。

対象外のスキルを引き取らせる

hermes curator status は、管理下の数と並べて対象外の数も 報告します。

curator-managed skills: 43 total  (agent-created=43  bundled=0)
  active     41
  stale       2
  archived    0

unmanaged (no provenance marker): 112 total
  pre-dates marker    34
  foreground-created  78
  never auto-staled or archived — `hermes curator adopt <name>` hands one over

この112本は手入れの*対象になりうる*のに、次の2つの理由のどちらかで、 ずっと生涯管理から見えないままです。

• 印より前からある — その記録は created_by が存在する前に書かれたので、

出どころの手がかりが一切ありません。誰が書いたかは記録からは本当に分かりません。

• 前面で作られた — 前面の skill_manage(create) は設計上 created_by: learn と

記録します（古い記録では未設定）。頼んで作ってもらったスキルは、頼んだ人のものだからです。

そのため、大きなスキル群が、ほとんど手出しできない状態のまま、 きちんと手入れされているように見えることがあります。adopt は、宣言によって この隙間を埋めます。

hermes curator list-unmanaged                    # itemize them, with reasons
hermes curator adopt <name> [<name> ...]         # hand specific skills over
hermes curator adopt --all-unmanaged --dry-run   # preview the full list
hermes curator adopt --all-unmanaged             # hand over everything (prompts)
hermes curator adopt --all-unmanaged --yes       # skip the prompt

引き取りは、バックグラウンドのレビューのフォークが書くのと同じ created_by: agent の 印を書き込みます。無操作の時計を戻すことはしません。引き取られたスキルは それまでの last_activity_at をそのまま保つので、すでに使わなくなったスキル群を 引き渡しても、90日の猶予が新たに手に入るわけではありません。長く放置されていた スキルは、引き取った次の処理で stale（や archived）になると考えてください。 それが狙いです。

引き取りが左右するのは*書庫入れ*だけです。バックグラウンドの自己改善のレビューは、 学びを得たスキルであれば、どれにでも手を入れ、書き直し、補助ファイルを足せます （手書きのもの、URL から入れたもの、同梱のもの、ハブから入れたもの、外部のもの、 固定したものを問いません）。ですから、学んだことは、誰が書いたかに関係なく、その作業を 受け持つスキルに反映されます。こうした書き込みはすべてスキルの台帳に記録されます。 書庫入れ（削除）ができるのはキュレーターの管理下にあるスキルだけで、固定したスキルは 対象になりません。書き込みが反映される前に確かめたい場合は、 skills.write_approval を有効にしてください（エージェントのスキルの書き込みに関門を置くを参照）。 レビューが手を入れた同梱やハブ由来のスキルは、手元で変更したものとして扱われるので、 hermes update / hermes skills update で上書きされなくなります。

エージェント製のスキルは、生涯の流れをひととおりたどります。

• active →（30日未使用）stale →（90日未使用）archived
• 固定されたスキルは、すべての自動遷移を素通りします
• 書庫入りしたものは hermes curator restore <name> で戻せます

特定のスキルを絶対に触られないようにしたいとき — たとえば頼りにしている手書きのスキル — は、hermes curator pin <name> を使ってください。次の節で説明します。

スキルを固定する

固定は、スキルを削除から守ります。キュレーターの自動的な書庫入れの処理からも、エージェントの skill_manage(action="delete") の呼び出しからもです。固定すると次のようになります。

• キュレーターは自動遷移（active → stale → archived）でそれを飛ばし、LLM のレビューにも触らないよう指示します。
• エージェントの skill_manage ツールはそれに対する delete を拒み、hermes curator unpin <name> を案内します。手直しや編集は通るので、固定を外してまた付け直すといった手間をかけなくても、落とし穴が見つかったときにエージェントが中身を良くしていけます。

固定と解除は次のようにします。

hermes curator pin <skill>
hermes curator unpin <skill>

この印は ~/.hermes/skills/.usage.json のそのスキルの記録に "pinned": true として保存されるので、セッションをまたいで残ります。

cron のどれかのジョブの skills: に名前があるスキルは、自動遷移については同じように守られます（参照が残っているかぎり、キュレーターがそれを古い扱いにしたり書庫入りさせたりすることはありません）。ジョブが停止中や無効でも同じです。skill_manage delete も止めたいときは、明示的に固定するほうが確実です。

固定できるのはエージェント製のスキルだけです。同梱のスキルやハブから入れたスキルに hermes curator pin を使うと、理由を添えて断られます。ハブから入れたスキルは、そもそもキュレーターによる変更の対象になりません。同梱の組み込みスキルは curator.prune_builtins: true にしたときだけ触られ、それも archive_after_days のあいだ使われなかった場合の書庫入れだけです。手を入れられたり、統合されたり、削除されたりすることはありません。

ごく一部の保護された組み込みスキルは、curator.prune_builtins の設定や固定の有無、LLM の判断に関わらず、書庫入りも統合もされないものとしてコードに直接書き込めます。これらは要になる使い勝手を支えているので、黙って書庫入りすると、そのスラッシュコマンドが何の知らせもなく「Unknown command」のエラーに変わってしまいます。（この集合はいま空です。最初の1つだった plan は、ディスク上にスキルを持たない組み込みの /plan コマンドへ昇格しました。）保護された組み込みスキルはキュレーターの候補の一覧から完全に外されるので、統合の処理がそれらを目にすることはありません。

「削除されない」よりも強い保証がほしいとき — たとえば、エージェントに読ませたまま中身を完全に凍結したいとき — は、~/.hermes/skills/<name>/SKILL.md を自分のエディタで直接編集してください。固定が守るのはツール経由の削除であって、自分のファイル操作ではありません。

利用状況の記録

キュレーターは ~/.hermes/skills/.usage.json に、スキルごとに1件の記録を持つ補助ファイルを保ちます。

{
  "my-skill": {
    "use_count": 12,
    "view_count": 34,
    "last_used_at": "2026-04-24T18:12:03Z",
    "last_viewed_at": "2026-04-23T09:44:17Z",
    "patch_count": 3,
    "last_patched_at": "2026-04-20T22:01:55Z",
    "created_at": "2026-03-01T14:20:00Z",
    "state": "active",
    "pinned": false,
    "archived_at": null
  }
}

数が増えるのは次のときです。

• view_count: エージェントがそのスキルに対して skill_view を呼んだとき。
• use_count: そのスキルが会話のプロンプトに読み込まれたとき。
• patch_count: そのスキルに対して skill_manage patch/edit/write_file/remove_file が走ったとき。

同梱のスキルとハブから入れたスキルは、この記録の書き込みからはっきり除かれています。

実行ごとの報告

キュレーターは実行のたびに、~/.hermes/logs/curator/ の下に時刻付きのディレクトリを作ります。

~/.hermes/logs/curator/
└── 20260429-111512/
    ├── run.json      # machine-readable: full fidelity, stats, LLM output
    └── REPORT.md     # human-readable summary

REPORT.md は、その回に何が起きたか — どのスキルが状態を変えたか、LLM のレビューが何と言ったか、どのスキルに手を入れたか — をすばやく確認する手段です。agent.log を grep せずに監査できます。

まとめに出る名前の対応表

複数のスキルを傘の下にまとめたり、似たものどうしを併合したりした回は、実行の最後に表示される利用者向けのまとめに、キュレーターが適用した old-name → new-name の対応が全部載ります。スキルごとの状態遷移の行とは別に出るので、名前の変更がまとめて起きたときも、JSON の報告を突き合わせずにひと目で気づけます。この案内は hermes curator pin の下にも出るので、新しい名前を固めたければ傘の名前をすぐ固定できます。

書庫入りしたスキルを戻す

キュレーターが書庫入りさせたものを、まだ使いたいときは次のようにします。

hermes curator restore <skill-name>

これでスキルは ~/.hermes/skills/.archive/ から現役のツリーへ戻り、状態も active に戻ります。同じ名前で同梱のスキルやハブのスキルがその後に入っていた場合は、上流を覆い隠してしまうので、この復元は断られます。

環境ごとに止める

キュレーターは既定で有効です。止めるには次のようにします。

• 1つのプロファイルだけ止める場合: ~/.hermes/config.yaml（または使っているプロファイルの設定）を編集して curator.enabled: false にします。
• 1回だけ止める場合: hermes curator pause を使います。この停止はセッションをまたいで続くので、resume で戻してください。

キュレーターは min_idle_hours が経っていなければ動かないので、作業中の開発マシンでは自然と静かな時間帯にだけ走ります。

関連

• スキルの仕組み — スキル全般の動きと、それを作る自己改善のループ
• メモリ — 長期記憶を保つ、並行して動くバックグラウンドのレビュー
• 同梱スキル一覧
• Issue #7816 — 最初の提案と設計の議論