Standard procedure for release notes

概要

エージェントは、バックグラウンドで神秘的に自動アップグレードされるからではなく、二種類のものが構造化された方法で保持されることで使用するほど賢くなる：安定した事実はメモリとなり、再利用可能な方法はスキルとして捕捉され、状況が一致したときに再ロードされる。メモリは何が起こったかを知ることを可能にする — クエリが一致したときに呼び出される。スキルは次回何をすべきかを知ることを可能にする — 状況が一致したときにロードされる。それらのトリガー、形態、変化の速度はすべて異なるため、統合することはできない。Hermesは/learnを提供し、エージェントが現在のセッションから実証済みの手順をSKILL.mdに抽出できるようにし、/skills pendingでレビューできるようにすることで、自己改善が無限に広がることを防ぐ。自己改善。健全なスキルは、いつそれを使うか、どのステップに従うか、成功とは何か、そして越えてはいけない境界が何かの四つのことを明示しなければなりません。重要なのはどれだけ記録するかではなく、それがレビュー可能で、再利用可能で、製品が変更されたときに更新可能であることです。

再利用できない経験は、ただの会話に過ぎません

異常にうまくいったセッションを思い出してください。あなたとエージェントは一緒に問題をデバッグしたり、本当に良いリリースノートを作成したりしました。その過程で、それを3、4回修正しました：範囲を絞る、形式を一貫させる、あのチェックを決して飛ばさない。結果は堅実なものでした。

一週間後、同じ種類のタスクがやってきます。もしその修正が先週のチャットログにしか存在しなければ、同じことを再び言っている自分に気づくでしょう — 調整は資産にはならず、一度きりのコストに過ぎなかったのです。

「使うほど良くなる」という背後にある本当の疑問はそれです。それはエージェントが神秘的に賢くなることではありません。それは、既に証明されたことが構造化された形で保持されることに関するものです。何を保持するか、どのように保持するか、そしてそれがどこに存在するかが、蓄積が本物か、または毎回のセッションが最初から始まるかを決定します。

1. 混同してはいけない二種類の蓄積

エージェントは根本的に異なる二つのものを蓄積します。

一致する例のペア:

• "このユーザーは結論を先に好む" → 記憶。これはあなたに関する事実です。
• "リリースノートを書く前に、バージョン番号とすべてのリンクが正しいことを確認する" → スキル。これは、その種のタスクが発生するたびに実行する手順です。

少なくとも三つの理由で、これらは統合できません：異なるトリガー（クエリ一致対状況一致）、異なる形態（短いエントリー対順序付けられたステップ）、および異なる変化率（毎日対毎月）。安定した手順を変化の激しい事実リストに混ぜると、安定した部分が失われます。完全な議論については、"Memory Is Not a Skill: How Hermes Agent Separates Factual and Procedural Memory." を参照してください。

この区別には即座に実用的な効果があります：同じ種類の行動を繰り返し直そうとしているのに気づいたとき、必要なのは記憶内の別の事実ではなく、スキルです。

2. スキルとはどのようなものか

Hermesでは、スキルは通常、トリガーやサポートする詳細を宣言するYAMLフロントマターを持つSKILL.mdです。大まかに言うと：

---
name: release-note-format
trigger:
  when: "user asks to write release notes"
---

# Standard procedure for release notes

1. Confirm the version number and release date
2. Group entries as Added / Fixed / Changed
3. Verify every external link resolves
4. Check for internal project names or ports; replace with placeholders
5. Confirm length fits the publishing channel's limits

重要なのはtriggerです：つまり、スキルを手動で呼び出すことはありません。対応する状況が認識されると、そのスキルは自動的に高優先度の指示としてロードされ、その実行を導きます。

Hermesは二層の組織化を追加します：

• スキルバンドル — 関連するスキルをまとめて、有効化、無効化、またはグループとして共有することができます。「リリースパイプライン」バンドルには、リリース前チェック、変更ログフォーマット、ロールバック手順などが含まれる場合があります。
• fallback_for_toolsets — スキルは、特定のツールセット呼び出しが失敗したときに、自分自身をフォールバックとして宣言することができるため、失敗時の経路にも明確な手順が存在します。

これらを組み合わせることで、スキルは孤立したSOPから、組み合わせ可能な作業手法へと変わります。

3. /learn: 1回の成功した実行をメソッドに変える

スキルをキャプチャする際に、会話を離れてファイルを書き込む必要はありません。Hermesは/learnを提供しており、エージェントが現在のセッションから保持する価値のある手順を抽出して新しいSKILL.mdにまとめることができます。

この設計の価値は、記憶が最も鮮明なうちに情報をキャプチャできることにあります。成功した協力の直後、あなたもエージェントも、どのステップが重要で、どの修正が不可欠だったかを知っています。1週間後に書き留めても、その詳細はすでに失われています。

しかし、自動的な蒸留には対処すべき問題があります：もしエージェントが自分に対して自由に行動ルールを追加できるなら、その行動は予測不可能になります。 Hermesはこれをレビュー手順で対処します — 保留中のスキルを/skills pendingで確認し、採用するかどうかを決定します。これはメモリ側の/memory pendingを反映しています。

自己改善は無制限の自己改変ではない。 信頼できる道は、新しい方法がまず見直し可能な規則となり、確認後にのみ効果を発揮することである。それが能力成長を説明可能にし、再利用可能にし、修正可能にする。

4. 健全なスキルが述べるべき四つのこと

これが有用なスキルと有害なスキルを分ける。四つのうちの一つでも欠けると、スキルは実際の使用で誤作動する。

まず、使用するタイミング。 トリガーとなる状況は具体的でなければなりません。「書類を扱うとき」は広すぎて、適さない文脈でも実行されてしまいます。「ユーザーがリリースノートを求めたとき」は十分に具体的です。あまりにも広範なスキルは、スキルがない場合より悪く、関連のないタスクを妨げます。

次に、従うべき手順。 手順は順序立てて実行可能でなければなりません。「品質に注意する」は手順ではありません。「すべての外部リンクが正しく動作するか確認する」は手順です。テストとして、他の人がこのスキルに従って実行し、概ね一貫した結果を出せるでしょうか？

三、成功の見え方。 成功基準がなければ、エージェントは自己チェックできず、実行が許容されるかどうかを判断できません。検証可能なものにしてください。例えば「3つのグループすべてが存在し、それぞれに少なくとも1つのエントリがあるか、またはグループが空であることを明示的に示すノートがある。」のように。

四、越えてはならない境界。 「例に実際の社内プロジェクト名やポートを使用しない」など、禁止事項を明確に記してください。境界はスキルで最も頻繁に省略される部分であり、インシデントの最も一般的な原因です。

すべての四つのスキルには共通する特徴があります：人間にもエージェントにも同じように読み取れるということです。何をしているか理解できるので、間違ったときに正確に修正することができます — これはそもそも修正可能であるための前提条件です。

5. 蓄積が実を結ぶ三つの段階

キャプチャは単一の行動ではなく、順序立てられたプロセスです。段階を飛ばすと品質が低下します。

ステージ1：まず実際の作業で手順を実証する。 想像でスキルを書かないでください。実際のタスクで実行されない手順は、記録されたときに間違いを固定化してしまうだけです。一度実行し、その過程で修正点を記録してください。

ステージ2：安定して再利用可能なステップを記録する。 ここでの両方の条件に注意してください — 安定している（来週には変わらない）ことと、再利用可能（この特定のケースに限らず適用できる）こと。一度きりの手順を記録しても価値はありません；メンテナンスに費やすコストが得られる利益を上回るでしょう。

ステージ3：製品、ツール、またはポリシーが変更されたときにスキルを更新する。 このステージは最も省略されがちです。6か月前に作成されたスキルで、移動されたエントリーポイントやその後調整された制限を参照している場合、古いガイダンスを出し続けてしまいます。古い経験を無期限に再利用することは、経験が全くないよりも危険です。なぜなら「実証済み」という信用度を持ってしまうからです。

実践的なメンテナンスの習慣：スキルの出力を手作業で何度も修正していると気づいたとき、それは有効期限切れです。回避策で対応するのではなく、更新してください。

6. 一般的な落とし穴

4行目は強調に値します：スキルライブラリの価値はそのサイズに比例しません。 期限切れのスキルは、十の良いスキルよりも大きな損失を生むことがあります。なぜなら、それは自動的にロードされ、信頼できるように見えるからです。

7. LightVelaのアプローチ：メソッドもユーザー資産として

HermesはMemory / Skillの分離をエンジニアリング可能にしましたが、まだMarkdownを直接編集する人を対象としています。LightVelaはクラウドでホストされたモデルを運用しており、ユーザー向けのファイルシステム操作を公開していないため、2種類の蓄積は次のように機能します：

• スキルは公開マーケットプレイスから入手 — すべてのスキルはSkills.shおよびClawHub、OpenClawとHermesが共有するスキルマーケットプレイスから来るため、一から作成する必要はありません。
• 会話でインストールと削除が可能 — Hermesにインストールするスキルを伝えると、Hermesが処理します。削除も同じ方法で行えます。その後、チャットで利用可能か確認してください。コンソールパネルでのインストールは近日対応予定です。
• メモリはコンソールで確認可能 — メモリページではエージェントが保持している内容を表示し、容量の上限を調整できます。追加や削除は会話を通じて行われます。
• モデルやチャネルを超えて安定 — モデルを切り替えてもスキルや自動化は消えず、接続されているすべてのチャネルで同じスキルとメモリが共有されます。
• 障害は追跡可能 — スキルが問題を起こした場合、診断で最近のログ（1、3、6、12、または24時間範囲を選択可能）を表示およびエクスポートして問題箇所を特定できます。

つまり、LightVelaでエージェントを使用することは、2つのものを蓄積することを意味します：あなたに関するメモリと、インストール済みで検証済みのスキルのセットです。どちらも特定のモデルより長くあなたの役に立ちます。

主なポイント

• 使用することで改善するのは、神秘的な自己アップグレードではなく、構造化された蓄積によるものです。
• 二つの種類は明確に区別する必要があります：記憶(Memory) は事実を保存します（クエリが一致したときに呼び出されます）、スキル(Skills) は方法を保存します（状況が一致したときにロードされます）。
• 同じ行動を繰り返し修正する場合、別の事実を追加するのではなく、スキルを取り込みます。
• /learn は詳細が新しいうちに方法を取り込みます；/skills pending は復習を提供するので、自己改善は無制限の自己改造ではありません。
• 健全なスキルは四つのことを明確に述べます：使用するタイミング、手順、成功基準、そして境界。
• キャプチャは3つの段階で行われます：実際の作業で証明する → 安定した再利用可能な手順をキャプチャする → 変更時に更新する。期限切れのスキルは、スキルがないよりも危険です。