Standard procedure for writing a PR description

概要

記憶とスキルはどちらも長期記憶ですが、根本的に異なります。記憶は宣言的記憶です：事実、出来事、結論、好みを短いエントリーとして保存し、クエリが一致したときに呼び出されます（MEMORY.md + memories/）。スキルは手続き記憶です：「状況Xが発生したときに何をすべきか」というSOPをトリガー付きYAMLと手順として保存し、シナリオが一致したときに高優先度で読み込まれます（skills/ディレクトリ + SKILL.md）。3つの厳格な制約がそれらを区別します：異なるトリガー（クエリ一致 vs シナリオ一致）、異なる形式（エントリー vs 手順）、異なる変化率（記憶は日々変化するが、スキルはそのまま保持されることがあります）。まだ何か月も）。両足で歩くエージェントは、あなたのことを理解し、仕事の仕方も知っています。

なぜこれら二つの概念が混同され続けるのか

もしHermes Agentに特に誤解されやすい設計が一つあるとすれば、それはメモリとスキルの明確な分離です。

ほとんどの人の最初の反応は三つの質問です：

• 「どちらも長期記憶ではないのですか？なぜ分けるのですか？」
• 「どちらもMarkdownなのに、なぜ一緒にしないのですか？」
• 「『エージェントデモのフロントエンドはローカルの開発ポートで動作する』ことを覚えること」と、『PRの説明を書くときにまず要約してから変更点を列挙することを覚えること』— これは同じことではないですか？」

短い答え：それは人間の脳もそれらを分けているためです。

1. 認知科学ではすでにこの区別があります：宣言的記憶 vs 手続き的記憶

心理学では、長期記憶には2種類あると長い間区別されてきました：

これら二つの種類の記憶は、どのように保存され、呼び出され、更新されるかで異なります。宣言的記憶は言語化することができます（言語チャネル）、一方で手続き的記憶は主に実行されます（運動チャネル）。心理学の実験では、海馬に損傷を受けた患者は宣言的記憶が著しく障害されていますが、鏡文字の書き取りなどの手続き的課題を学習することはまだ可能です — 二つの独立した経路であり、一つの経路の二つの表現ではありません。

Hermes Agentはその区別をまさに自分のシステム設計に取り入れています：

• メモリ（memories/、MEMORY.md）: エージェントの宣言的記憶。
• スキル (skills/): エージェントの手続き記憶。

2. 記憶: エージェントが述べられること

記憶システムは事実、出来事、結論、好みを保存します：

• 「ジャスミンはエージェントデモのグローバルサイトで作業しています。」
• 「先週、ヒーローセクションがアニメーション付きグラデーションに変更されました。」
• 「このプロジェクトはNext.jsで動作しており、フロントエンド開発サーバーはローカル開発ポート上で動作しています。」

その特徴：

• 宣言的: 短い文章やエントリとして存在し、プロンプトに直接引用できます。
• 要求に応じて呼び出される：関連するトピックが出てきたとき、FTS5のマッチングによって関連するエントリが引き出されます。
• 揮発性：新しいエントリが追加され、古いものはreplaceまたはremoveされます。

記憶はエージェントのノートブックのようなもの — デスクの上に開かれた状態で置かれ、具体的な事実が書き込まれています。

3. スキル：エージェントができること

スキルはタスクのクラスに対する標準的手順を保存します。典型的なHermesスキルは、トリガー条件とサポートするツールセットをYAMLフロントマターで宣言するSKILL.mdです：

---
name: pr-description-format
trigger:
  when: "user asks to write a PR description"
fallback_for_toolsets: [git, code-review]
---

# Standard procedure for writing a PR description

1. Summarize the goal of the change in one sentence
2. List the changes (grouped by module)
3. Blast radius
4. Testing status
5. Related issue / rollback plan

その特徴：

• 手順的: 「いつ起動するか + どう行うか」として存在し、再利用可能な標準作業手順書(SOP)に近い。
• シナリオによって起動: エージェントが一致する状況を認識すると、そのスキルは高優先度のプロンプトとして自動的に読み込まれ、その行動を導く。
• 比較的安定している: 一度スキルが定着すると通常はそのまま保持される。変わるのは、スキルに結びつくシナリオやメモリ内の素材である。

スキルをエージェントの筋肉記憶と考える — 思い出す必要はなく、動作が自動的に起こる。

Hermesのユーザーは、/learnを実行して、エージェントに「このセッションで記録する価値のある部分」を新しいSKILL.mdに蒸留させることもできます — まるでメンターが方法を弟子に伝えるように。

4. 「なぜそれらを統合しないのか？」 — 3つの厳しい制約

誰かが尋ねるでしょう：両方ともMarkdownで、どちらも長期記憶なのに、なぜ一緒にしないのですか？

なぜなら、それはうまくいかないからです。その理由は、USER.mdとMEMORY.mdを分けている3つの制約に似ていますが、ここではさらに強力です。

制約1：異なるトリガー

• 記憶は「クエリが一致したときに呼び出される」（FTS5とセマンティックサマリー付き）。
• スキルは「シナリオが一致したときにロードされる」、通常は明示的なトリガー付き（trigger.when: "user asks to write a PR description"）。

統合すると、エージェントは事実を引用しているのか手順に従っているのかの把握を失う。

制約 2: 異なる形式

• 記憶は短い文、事実、エントリ（「[2026-07-30] agent-demo フロントエンド ローカル開発ポート」）。
• スキルは手順、テンプレート、制約、通常は YAML フロントマターと「ステップ 1 / 2 / 3」の順序付き。

一緒にまとめられていると、エージェントは「これは背景情報なのか、それとも今すぐ実行すべきことなのか？」と判断できません。

制約 3：変化の速度が異なる

• 記憶は毎日変化する（単一のセッションで1〜2件のエントリが追加される場合があります）。
• スキルは数か月間変わらず残ることがある（PR説明用のSOPは半年間修正の必要がありません）。

これらを一緒にすると、高頻度で変化する事実のエントリが安定したSOPに押し流されてしまいます — まるで憲法と卓上カレンダーを同じノートに綴じ込めるようなものです。

5. 実際のシナリオ：/learn と記憶が一緒に働く

あなたがエージェントに次のように伝えたとします:

「今後、私たちのチームはPRの説明をこのフォーマットで書きます：1文での要約、変更点のリスト、影響範囲、テスト状況。また、このプロジェクトはagent-demoと呼ばれ、フロントエンドはローカルの開発用ポートで動作していることを忘れないでください。」

よく訓練されたHermes Agentはこれを次のように処理します：

• 前半 → /learnパス、新しいスキルを書く：pr-description-format.md、user asks to write a PR descriptionによってトリガーされる。
• 後半 → addの原子操作、1つのメモリエントリを書く：- [2026-07-30] agent-demo: frontend dev server on a local dev port。

次回「PRの説明を書いて」と言うと、エージェントは以下のようにします：

1. シナリオとスキルを一致させる: pr-description-format.md は高優先度のプロンプトに入ります。
2. クエリによるメモリの一致: 現在のプロジェクトが agent-demo であり、ローカルの開発ポートで実行されていることを認識しています。
3. 両方を組み合わせる: チーム標準に従い、特定のプロジェクトに適した PR 説明を作成します。

事実の記憶と手順の記憶を組み合わせることで、結果は部分の合計以上のものになります。

6. スキルバンドルと fallback_for_toolsets

Hermes はスキルの上に2層の組織を追加します:

• スキルバンドル: 関連するスキルがひとまとめにパッケージ化されます。たとえば「リリースパイプライン」バンドルには、pre-release-checklist、changelog-format、deploy-rollback が含まれ、単位として有効化、無効化、または共有されます。
• fallback_for_toolsets: スキルは、ツールセットが失敗した際にそのツールセットをバックアップすることを宣言できます。たとえば、git のツールセットがエラーを出した場合、手動でのリベース復旧手順を持つスキルが起動します。

これらを組み合わせることで、スキルは単一のSOPから組み合わせ可能な作業手法へと変わります — ユーザーがエージェントに持ち込む作業全体の方法が、共有可能な資産として捉えられます。

7. 新しい考えではありませんが、適切に実装されることはまれです

事実記憶と手続き記憶の層状化は、AI界隈で長い間議論されてきました。実際にそれを工学的に実現し、ユーザーが見える、編集でき、再利用できるようにすることが、Hermesが比較的先を行っている点です — すべての層を具体的なディレクトリ、フィールド、コマンドにマッピングしています：

その層構造を製品の文脈に持ち込むと、実際の可能性を持つ形が得られます：

• メモリはあなたとエージェントの間で共有されるアーカイブです。
• スキルとは、あなたがエージェントにもたらす作業方法論です。

これら二つが組み合わさることで、エージェントはあなたを理解し、作業方法を知っているパートナーになります — 単に記憶力のあるチャットボットではありません。

8. LightVela: メモリとスキルの両方をユーザーの資産に変える

Hermes は既にメモリ/スキルの分割を技術的な意味で使えるようにしましたが、それでも開発者向けのMarkdownに過ぎません。LightVelaのアプローチは、そのレイヤーを技術的機能からユーザーの資産に引き上げることです：

• 個人用スキルライブラリ：ユーザーは、自分自身のスキル（ワークフロー）をプロンプトを収集するように収集、編集、共有でき、それらをトリガーシナリオに紐付けることができます。あなたの書き方のパターン、レビュー手順書、翻訳基準はすべてスキルになることができます。
• 個人用メモリライブラリ：エージェントがあなたについて保持しているすべての事実上のメモリは透明で、閲覧可能、訂正可能、削除可能です — ~/.hermes/MEMORY.md を編集する必要はありません。
• チームレベルでの再利用：スキルとメモリの両方がチーム単位で保持できるため、新しいメンバーはチームの共有メモリや共有手法を自動的に引き継ぎ、口伝えに頼る必要がありません。
• 最短経路: 「二段階」モデルが気に入っても、Ollama、SSH、systemd、そして~/.hermes/バックアップを扱いたくない場合、LightVelaが完成品としてそのモデルへの最短経路です。

言い換えれば、エージェントをLightVelaで訓練することは、一度に二つの資産を蓄積することを意味します。それはあなたに関するメモリと、あなたのスキルのコレクションです。これら二つの資産は長期的にあなたのものであり、モデル自体よりも重要です。

重要なポイント

• メモリ ≠ スキル。前者は宣言的記憶（述べることができる事実）、後者は手続き的記憶（実行される方法）です。
• 彼らを分けている三つの厳格な制約：異なるトリガー / 異なる形態 / 異なる変化速度。
• 成熟したエージェントは両足で歩く必要がある — 事実を覚えることと手法を覚えること。
• LightVelaは両方をユーザーの資産に変えるので、「自分のエージェントをトレーニングする」ことがスローガンではなく、構築できる製品体験になる。

ここまでのまとめ

このカテゴリ全体では、5つの記事が網羅している：

1. Hermes AgentがOpenClawと異なる点（蓄積 vs 連結）
2. Hermes Agent があなたを覚えている方法（4つの構造化された記憶層）
3. なぜ Hermes Agent は記憶を2つに分けるのか（USER.md 対 MEMORY.md）
4. なぜ記憶が多いだけでは良くないのか：Hermes Agent が長期記憶をフィルタリング、キュレーション、更新する方法（4つの鉄則）
5. 記憶は技能ではない：事実記憶と手順記憶の違い（両足で歩く）

締めの一言：次世代のエージェントにとっての堀は、モデルのサイズではなく、そのエージェントが本当にあなたを知っているか（メモリ）と方法を持っているか（スキル）です — そしてその二つが長期的に確実に機能するかは、それが生き続けるかにかかっています。だからこそ、LightVelaは存在するのです。