関連: Hermes Agent / Hermes Agent ツールセット整理 / PKMを汚染・腐敗させない

Awesome Hermes Agentの読み方

Awesome listは候補を見つける場所であって、導入候補の一覧ではない。

Hermesの周辺には、skill・memory・proxy・orchestrationを増やす道具が多い。 でも、すでにHermes本体、Irisのルール、既存skill、Nix管理、Gatewayがある環境では、新しい層を足すほど「どこが判断したか」が曖昧になる。

まず既存機能と重なるかを見る。重なるなら、導入ではなく設計だけ読む。

2026-07の判断

lintlangだけは試験候補

lintlangはskillや設定を静的に点検する。新しい能力を常駐させるものではない。

今の問題はskillが足りないことではなく、増えた指示や設定が互いに矛盾していないかを低コストに確かめることにある。

試すなら、本体の~/.hermesではなく、コピーした少数の非privateなSKILL.mdと設定だけを読む。

• global installしない
• Python source解析は使わない。localhost Ollamaへ接続しうるため
• 自動修正、CI、pre-commitには繋がない
• 警告は結論ではなく、既存ルールを読み直すきっかけとして扱う

token削減はproxyより先に運用を削る

llmtrimは、tool schemaや履歴をモデル送信前に圧縮する。agentburnで見えた固定input overheadには一見効きそうだった。

ただしMITM proxyとして動き、ローカルCA、shell設定、daemon、利用量DBを持つ。promptと認証情報が通る場所を増やすことになる。OpenAI Codexの現在の通信経路にも対応が確認できなかった。

先にやるのは、不要toolsetを切ることと、無駄なprocess pollingを減らすこと。proxyは、その後でも遅くない。

自動でskillやmemoryを育てない

SkillClaw、Ditto、skill factory、dojoの類は見送る。

便利そうに見えても、skill・profile・session記録の別レイヤーを増やす。自動改善には追加のモデル呼び出しも要る。

Irisでは、skillは問題を解いた後に必要なものだけ残す。memoryも、会話の採掘先ではなく、繰り返し言わせないための最小の記録にする。

orchestrationを重ねない

oh-my-hermes、PolyBrain、ACP skillのような仕組みは、既存のdelegation、Claude Code委譲、Herdr、task trackingと役割が重なる。

複数の司令塔を置くと、失敗時にどこへ戻ればいいか分からなくなる。今の構成で足りない場面が実際に出るまでは増やさない。

skill packは一括導入しない

大規模skill packは、優れた個別skillを含んでいても一括では入れない。

選択肢が増えると、skillの探索・読み込み・保守自体がコストになる。足りない能力が明確になったときだけ、1つを取り出してHermes/Iris向けに読み替える。

検討した候補

試験候補

• hermes-labs-ai/lintlang
  • skill、config、promptの静的lint。
  • credentials・常駐・永続stateを増やさない。
  • Python source解析はOllamaへ接続しうる。隔離したMarkdown/YAML/JSONだけを読む試験に限る。

設計だけ参考にする候補

• Socialpranker/agentburn
  • state.dbをread-onlyで集計する。月次か設定変更の前後に一時実行する候補。
  • 通常reportにもsession titleやtool argumentが混ざりうる。共有用ではない出力を外部へ出さない。
• luoyuctl/agenttrace
  • Hermes、Codex、Claude Codeを横断してsessionを読む。
  • local cache/indexにsession由来情報を複製する。横断比較が本当に必要になった時だけ隔離実行する。
• markoblogo/abvx-agent-skills
  • minimal diff、reversible task、evidence ledgerの考え方は読む価値がある。
  • 80以上のskill packとしては既存skillと重複しすぎる。
• baoyu0/code-assembly-skill
  • 作る前に探して組み立てるという判断は使える。
  • repository自体はdeprecatedで、SOULへの強い注入も合わない。

見送り

• fkiene/llmtrim
  • MITM proxy。ローカルCA、shell設定、login daemon、利用量DBを持つ。現在のCodex経路での有効性も未実証。
• AMAP-ML/SkillClaw
  • configを書き換え、skillをcopy/delete/syncする。background model call、credential設定、proxyも増える。
• ohad6k/ditto
  • coding agentの履歴から別のprofile/memoryを作る。個人ログの集約面とmodel callを増やす。Hermes log自体は対象外。
• ZeroPointRepo/youtube-skills
  • TranscriptAPIのaccount、API key、creditが必要。既存video-content-ingestionの範囲で足りる。
• tleham/litprog-skill
  • Claude hook前提。tangleがsourceを上書きし、path handlingにも不安がある。
• duruonanni/hermes-skill-kit の memory maintenance
  • 古いHermes CLI前提。memory削除を含む回復手順があり、IrisのPKM境界とも競合する。
• witt3rd/oh-my-hermes
  • .omhのpersistent stateと多数のsubagentを前提にする第二のorchestration。
• Romanescu11/hermes-skill-factory / Yonkoo11/hermes-dojo / Lethe044/hermes-skill-marketplace / okdk7788/skill-evolution
  • 自動でskillを生成・改善・公開する。skillを必要な分だけ残す今の運用と逆向き。
• mosesman831/PolyBrain / Rainhoole/hermes-agent-acp-skill / ReinaMacCredy/maestro / tiann/execplan-skill
  • 既存delegation、Claude Code委譲、Herdr、task trackingを再包装する。司令塔を増やさない。
• mlinquan/hermes-snow-search
  • 漢字2-gramはよいが、日本語全体への効き方は限定的。既存session_searchと重複し、会話本文などをRAMに複製する。
• 0xrsydn/nix-hermes-agent
  • stable/nightly候補を分ける更新方針だけ参考にする。system module本体は既存Home Manager運用と重い。

判断の順番

1. Hermes標準機能、既存skill、既存MCPで代替できないか
2. 常駐・proxy・hook・新しいmemory層を増やさずに使えるか
3. 読む範囲、書く範囲、外部通信、credentialへの到達範囲を説明できるか
4. 隔離環境で一時実行して、実際の不足を埋めるか確かめられるか
5. 取り除く手順まで先に書けるか

「便利そう」は導入理由にならない。今の構成を少しでも単純にできるかだけを見る。