mcpField
M
memory-hygiene

memory-hygiene

github.com/huytieuエージェントワークフロー1.3k134 回インストール1 週間前に更新
リポジトリ

memory-hygiene について

memory-hygiene は、エージェントの永続メモリと環境に依存するナレッジノートを点検するスキルです。現在の環境で事実を検証し、信頼度を記録して、アーカイブや削除はユーザーの確認に委ねます。

主な機能

  1. 01メモリとナレッジノートの走査
  2. 02環境依存の主張の分類
  3. 03項目の検証と信頼度の更新
  4. 04アーカイブ案付き監査レポートの作成

活用シーン

  1. 01パス、URL、IDの古さの確認
  2. 02誤った記憶によるタスク失敗の調査
  3. 03確認済みの古い事実の修正
  4. 04点検内容とアーカイブ案の整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/huytieu/cog-second-brain --skill memory-hygiene

インストール後、Claude Code で/memory-hygieneを入力して読み込まれたか確認します。

詳細

COG Memory Hygiene Skill

目的

古くなっているのに自信ありげという失敗モードを防ぎます。記録した当時は正しかったメモリやナレッジノート（「Webhook は X にある」「ボード ID は Y」など）が、環境の変化後も気づかれないまま古くなり、検索時に依然として上位に表示され、実行に移される状態です。

システム上の対応（「From Model Scaling to System Scaling: Scaling the Harness in Agentic AI」、Gu、UC Berkeley、arXiv:2605.26112 を参考）：信頼性を保存項目の属性ではなく、実行時の判断にします。稼働中の環境に照らして再検証し、将来の検索で信頼性を考慮できるよう、各項目に last_verified と confidence を第一級のフィールドとして保持します。

呼び出すタイミング

  • /memory-hygiene
  • 「メモリを監査して」／「古くなったメモリがないか確認して」
  • メモリが誤作動した後（検索された情報が間違っていた場合）
  • デフォルトの頻度：毎月

対象範囲

次の 2 つのストアを確認します。

  1. エージェントメモリ — エージェントが永続メモリファイルを保存する場所（例：Claude Code の自動メモリディレクトリ）。インデックス自体を除くすべての項目を確認します。
  2. 永続ナレッジノート — 環境に関する記述（パス、URL、ID、ツール名など）を含む 05-knowledge/** ファイル。

依頼された場合は、一部（「参照項目だけ」など）の確認でもかまいません。

記述の分類

各項目の記述を次の 2 つに分類します。

分類例対応
環境依存ファイル／ディレクトリのパス、リポジトリ名、ブランチ名、チャンネル ID、ボード ID、URL、API エンドポイント、cron／ルーチン ID、CLI 名、バージョン番号、「X は Y にある」稼働中の環境に照らして検証します
好み／判断トーンのルール、書式ルール、「X を絶対にしない」、人物に関する事実、戦略上の背景環境チェックはできません。新しい項目との内部矛盾だけを確認します

検証方法（手軽なものから）

  • パスとファイル：ls／test -e。項目に記載されたスキル、コマンド、エージェントが、記載のパスに存在することを確認します。
  • URL：HEAD／GET（curl -sI）でアクセスし、404 またはログイン画面へのリダイレクトがあれば報告します。
  • リポジトリ／ブランチ：手軽にできる場合は gh repo view、git ls-remote を使います。
  • ID（チャンネル、ボード、ルーチンのトリガー）：MCP／CLI の確認が 1 回の呼び出しで済む場合に限り検証します。それ以外は unverifiable-cheaply として記録し、信頼度は変更しません。
  • 項目間の矛盾：新しい項目を優先し、古い項目を報告します。

1 項目あたり約 1 分を超えて時間をかけないでください。これは衛生管理であり、調査ではありません。検証不能 ≠ 古くなっている。

記録

項目の確認後、その本文は変更せず、frontmatter の metadata: ブロックをその場で更新します（検証によって誤りと判明した事実を修正する場合を除く）。

metadata:
  type: reference
  last_verified: 2026-07-10
  confidence: high   # high = verified now | medium = unverifiable cheaply | low = partially drifted
  • 問題なく検証できた → confidence: high に設定し、日付を記録します。
  • 手軽に検証できなかった → 以前の信頼度（または medium）を維持し、日付を記録します。
  • 一部が古くなっていた → 古くなった事実を本文で直接修正します（レポートで確認できます）。修正が完全かどうか不確かな場合に限り、confidence: low に設定します。
  • 完全に古くなっていた → 削除せず、アーカイブを提案します。 レポートの「アーカイブの提案」セクションに記載し、ユーザーの確認後にのみアーカイブします。

ループ（/loop-engineering を参照）

項目リストを最後まで確認するまでスキャンし、各項目の時間を約 1 分に制限します。確定的な検証に使うのは環境そのもの（test -e、curl、gh）です。項目が「まだ存在するはずだ」というエージェント自身の記憶は使いません。人による確認が必要な操作：すべての削除／アーカイブ。

レポート（単一ファイル）

各スイープにつきレポートを1件、01-daily/YYYY-MM-DD-memory-hygiene.md に作成し、次の4つの変化に関する問いを軸に構成します。

  1. 何が残っていますか？ — 種類別（ユーザー／フィードバック／プロジェクト／リファレンス）の件数。
  2. 何が更新されましたか？ — 本文が修正されたエントリと、その修正前 → 修正後。
  3. 何を測定していますか？ — スコアカード：verified / unverifiable / drifted / propose-archive の件数と、前回のスイープレポートとの差分（ドリフトの傾向は、単発の確認では見落とす長期的な指標です）。
  4. 何を監査できますか？ — 今回のスイープで行ったすべての変更を、このレポートに1行ずつ記録します。Git が追跡しないストアでは、レポートが監査記録そのものです。

レポートの末尾にアーカイブの提案セクションを設け、各項目について根拠を1行ずつ明記します。判断が必要な項目がある場合は、確認待ちの行を追加します。

ルール

  • 削除／アーカイブは提案のみにとどめ、スタンプと検証済みの事実修正は直接適用します。
  • スイープ中にエントリの語り口を書き換えたり、構成を変更したりしないでください。
  • メモリーインデックスが名前変更後または存在しないファイルを参照している場合は、インデックスを修正してください。
  • スイープ自体はメモリーに残さないでください。記録はレポートファイルに残します。

コメント

Markdown 対応