memory-collector

メモリ収集ツール

最も豊富なメモリソースは、このマシンのディスク上で手つかずのまま眠っています。これまでに実行されたすべてのコーディングエージェントのセッションです。判断、注意点、未解決の質問、人々、そして時折飛び出す引用したくなるような発言が詰まったトランスクリプトは、どれも検索できず、JSONL の中で朽ちていくばかりです。

このスキルは収集ツールです。予算を設定し、カーソルで追跡しながらトランスクリプトを掘り起こし、現在の環境で利用できるあらゆるメモリストアに、永続的な知識を植え付けます。memory-gardener と同様に ストレージに依存せず（実行時に機能を検出します）、ソースを認識します（コーディングツールがセッションを保存する場所を把握しています）。抽出プロンプトは、Jeremy Scherer による EI の抽出パイプラインから引き継いだものを prompts/ に収録しています（MIT）。

両者の連携：収集ツールが植え付け、ガーデナーが剪定します。収集では、意図的に重複に近い項目や過剰な増殖を許容しています。収集結果を手入れするために、ガーデナーの検証ゲート、重複整理、肥大化した項目の分割機能があるのです。収集ツールを完璧にするのではなく、両者が収束するようにしてください。

基本ルール — 安全性の契約

1. ソースは読み取り専用です。 トランスクリプトファイルを変更、移動、削除してはいけません。
2. ストアへの追加のみ行います。 収集ツールはメモリ項目を作成・更新しますが、削除はしません。削除すべきものに見える項目の処理は、ガーデナーの役目です。
3. 実行ごとに予算を設定します。 デフォルトは3 セッション（または約 150 メッセージ）です。このホストでサポートされているすべてのソースから、条件を満たす新しいセッションを優先して選び、lastMessageAt の降順、次にツール名、セッション ID の昇順（コードポイント順。同じ ID が重複する場合はパスで決着）に並べます。予算を使う前に、進行中、完了済み、内容がごく短いセッションを除外します。予算に達したら停止し、残りは次回に回します。
4. 進行中のセッションはスキップします。 直近約 30 分以内に変更されたトランスクリプト、またはツールが明らかにセッションの途中にある場合はスキップします。書きかけのセッションはうまく抽出できません。次回の実行時に処理できます。
5. シークレットは絶対に保存しません。 コーディングのトランスクリプトには、トークン、接続文字列、ARN、キーが含まれています。抽出した値が認証情報のような形式なら、破棄してください。付属のプロンプトでは引用にこれらが含まれないようにしていますが、保存するすべてのフィールドに同じ基準を適用してください。
6. 慎重さを徹底してください。 付属のプロンプトは、結果が空であることが最も多い応答となるように調整されています。その方針を守ってください。ノイズは欠落よりも有害です。
7. 出所情報は必須です。 保存するすべての項目にソース ID を付けます（フェーズ 4 を参照）。セッションまでたどれない項目は、うわさにすぎません。

フェーズ 0 — 調査

トランスクリプトのソース。 このスキルには、依存関係のない Node リーダーが含まれています （readers/）。読み取り専用のソース横断セレクターを使います： node readers/select.mjs --cursor <local-cursor-snapshot.json> --host <host> --budget 3。 初回実行時は --cursor を省略します。ホストのカーソル全体をページングして取得し、非公開のローカルスナップショットにコピーしてください。切り詰められた応答で代用してはいけません。ソースを調査するには node readers/<tool>.mjs --list --limit 100 --offset 0 を使い、必要に応じてページングします。収集に --since highWater を使ってはいけません：未解決の古い欠落箇所だけでなく、バックログも除外されます。セレクターはすべての履歴を内部でインベントリ化しますが、返すのは上限付きのメタデータであり、トランスクリプト本文ではありません。セッションストアを手作業で解析してはいけません：リーダーには、形式上の落とし穴（サイドチェーンファイル、ユーザーメッセージを装ったツール結果レコード、情報が失われる CWD エンコーディング）への対処がすでに組み込まれています。

ツール	リーダー	セッションの保存場所
Claude Code	readers/claude_code.mjs	~/.claude/projects/<encoded>/<uuid>.jsonl
Pi / OMP	readers/pi.mjs	~/.pi/agent/sessions/（および ~/.omp/…）
Codex	readers/codex.mjs	~/.codex/state_<N>.sqlite + rollout JSONL
OpenCode、Cursor	まだありません — 追加方法については readers/README.md を参照してください	ローカルアプリデータ

メモリストア。 ガーデナーのフェーズ 0 とまったく同じ方法で、ツールのインターフェイスから機能を特定します。メモリの検索／変更、ナレッジグラフ、日記、統計などです。ツール名を決めつけないでください。

カーソル。 前回の収集状態を見つけます：collector-cursor タグが付いたメモリアイテムまたはアーティファクトです。既存のすべてのフィールド、処理済み／スキップ済み ID、タイムスタンプ、保存済みアイテムへの参照、プロベナンス、未知のソースを保持してください。ネストされた Mac の sources マップと、フラットな dev マップ／skipped_trivial 配列の両方が readers/collector-state.mjs でサポートされています。レガシーの highWater／high_water_mark 値は履歴情報としてのみ扱います。変更せずに残し、走査の境界として使わないでください。新しいセッションごとのリビジョンと部分的な進捗は、追加されるサイドカー collectorV2.sources.<tool>.sessions.<id> に保存されます。完了の判定には、サイドカーとレガシーの解決済み ID を使います（グローバルなタイムスタンプは使いません）。 カーソルがない場合の初回実行では、対象となる最新のセッションを少数選択します。古いセッションはすべて引き続き検出可能です。以降の実行では、新たに到着したものから検出を開始し、未解決の履歴をさかのぼります。新しい入力が継続的に届く場合、最新のものを優先することで履歴の処理が滞る可能性があります。公平性のための割り当てや、別のポリシーが示唆されているわけではありません。

フェーズ 1 — 選択

予算を割り当てる前に、readers/select.mjs を使ってソースを統合してください。ツールごとに別々に予算を割り当てたり、ソース順に処理したりしないでください。この処理では、30 分の mtime とメッセージ時刻のガード、解決済みリビジョンの確認、および既知の自明なフィルターが適用されます。アクティブだと判明しているセッションには --live-id <tool>:<id> を渡してください（複数回指定できます）。現在の PI_SESSION_ID は自動的に除外されます。ライブ中または不安定なセッションが自明／完了としてマークされることはありません。読み取り不能または不正な形式のソースは未解決のまま報告され、空として黙って分類されることはありません。

返される selected エントリは候補であり、予算を消費したものではありません。抽出前に、付属の --session リーダーを使って人間との実際の会話であることを確認してください。未知の自動化テンプレートについては、この確認が必要です。変換後のリビジョンと fileVersion が選択されたエントリと一致することを確認してください。明らかに機械生成されたセッションの場合は、正直な skipTrivial 遷移を記録し、更新されたスナップショットと残りの予算を使ってセレクターから補充してください。失敗したセッションや一部しか分析できなかったセッションを、実行予算を超えて追加のセッションで置き換えてはいけません。

実際の会話を優先してください。 エージェントの自動化によってもセッションは生成されます。たとえば Pi ストアには、人間のセッション 1 件につき、機械的なランナージョブのセッションが 1,000 件保存されている場合があります。ごく短いセッション（メッセージが約 4 件未満）や、冒頭のメッセージが明らかに機械生成のジョブプロンプトで、内容のある人間の応答が続かないセッションはスキップし、そのリビジョンについてカーソルに skipped-trivial として記録してください。変更されたセッションや再開されたセッションは、安定してから再検討してください。ノイズに予算を費やすと、コレクターの処理が滞ります。

フェーズ 2 — 変換

node readers/<tool>.mjs --session <id> を実行すると、セッションはすでに整理された会話に変換されています。含まれるのは人間とアシスタントのテキストのみで、思考ブロック、ツール呼び出し／結果、システムノイズ、サブエージェントのやり取りはリーダーによって除去されています。この出力を基に、次のように処理します。

• 完全修飾メッセージ ID を作成します。<tool>:<machine>:<session>:<reader msg id>（例：claudecode:mbp:0a1f…:42）。引用と出典情報ではこれらを参照します。
• セッションはウィンドウ（約 20～40 メッセージ）に分けて処理します。各ウィンドウ自体が「Most Recent Messages」となり、それ以前の内容を簡潔にまとめた部分が「Earlier Conversation」となります。提供されるプロンプトはこの分割を前提として構成されており、分析対象は常に直近のウィンドウのみです。
• readers/collector-state.mjs の pendingMessages(cursor, session) を使い、再試行／再開時に確認済みのメッセージフィンガープリントを除外します。コンテキスト用に会話全体を保持しますが、再度取り込むために使ってはいけません。フィンガープリントがない旧形式の処理済みレコードについては、記録された最終メッセージのタイムスタンプ（それだけが保持されている場合は解決時刻）より後の部分のみを分析してください。旧形式のレコードを再処理する前に、既存のソースタグ付き項目を照合してください。時刻が不明な旧形式のデータは legacy-review として報告し、推測してはいけません。最初の安定した V2 遷移では、すでに解決済みの旧形式の部分を再取り込みせずにフィンガープリント化します（legacyBaseline:true）。以降の編集では、以前のタイムスタンプによる区切りではなくハッシュを使用します。このベースライン設定前に行われた同一タイムスタンプの書き換えは、確実に検出できません。これは旧形式の制約であり、すべてを再取り込みしてよいという意味ではありません。

フェーズ 3 — 抽出

各ウィンドウで同梱のパイプラインを実行します。コーディングツールのセッションでは technical_context: true を指定します（Technical カテゴリが優先されます）。

1. トピック — prompts/topics.md：スキャンで候補トピックを検出 → マッチングで既存のメモリとそれぞれ照合（慎重に判断し、確信がなければ「新規」）→ 更新で適切な分野の下にレコードを書き込みます（Event のナラティブ、Technical は 蓄積し、統合しない、それ以外はすべて 統合し、蓄積しない）。引用も一緒に保存します。
2. 人物 — prompts/people.md：スキャンで人物を検出（確信度 1～5、識別子の取得、自分自身・仮定上の人物に対するガード）→ まず識別子、次に名前で照合 → 人物の分野の下に更新します。コーディングセッションでは、ほとんどのウィンドウで該当者なしとなります。それで正しい動作です。
3. イベント — prompts/events.md：セッションごとに一度、「The Night We Debugged the CPU」のキャンペーン振り返りテストを実施します。該当なしが通常です。
4. ファクト — prompts/facts.md：不足ファクトのリストを管理している場合に限り実行します（カーソルの横に保持）。リストがなければ実行しません。

フェーズ 4 — 保存

抽出結果を検出したストアに書き込み、フィールドをストアのスキーマに対応付けます（confidence／exposure-impact は重要度に相当するフィールドへ、categories はタグ／コンテナへ。ストアで保持できないフィールドは、格納先をでっち上げずに破棄します）。すべてに source:<tool>:<machine>:<session> と collected:<ISO date> のタグを付けます。

ストアが最近のアイテムと未レビューのアイテムを区別する場合は、新規アイテムが新規であると明確に分かるようにします。ガーデナーの検証ゲート（フェーズ 1）は、これらの新規アイテムが進むべき入口です。高速ストアと構造化ナレッジストアの両方がある場合は、要約を検索が行われる場所に、構造（エンティティ、リンク）をグラフが存在する場所に配置します。

リトライ時の安全性と意味的な重複排除は別のものです。 各ウィンドウの書き込み前に、サニタイズ済みの抽出計画、安定した windowKey(host, session, messages, cursor)、ストアごとの操作キー／対象を、カーソルの横にある保留中アーティファクトに保存し、読み戻して確認します。その後、計画 ID を指定して beginWindow を呼び出し、ストアへの書き込み前にカーソルの意図を保存して読み戻し、確認します。これにより、ソースが後で書き込み応答／チェックポイントの前に元に戻った場合でも、影響を受ける古いメッセージの確認が無効になり、新しいリビジョンの世代が記録されます。外部の計画だけでは不十分です。選択処理から保留中の意図が見える必要があります。リトライ時にはその計画を再利用します。各操作にはキーを付け、再作成の前に厳密な検索／読み戻しで照合します。plantOnce に、必要なストアアダプターの契約が記載されています。書き込みのタイムアウトは、何も書き込まれなかった証拠にはなりません。reconcileWindow は、計画されたすべての操作について結果または不在が確認された後にのみ使用します。これはレシートと計画の来歴を保持しますが、メッセージを確認済みにはしません。ソースが変更された計画は再利用せず、古い書き込みを照合してから、現在保留中のメッセージを分析します。ストアが不確かな書き込みを照合できない場合は、保留状態のままにし、無条件にリトライするのではなく失敗を報告します。 すべてのパイプラインと必要なストアへの書き込み（結果が空の場合も含む）が確認された後にのみ、ウィンドウのチェックポイントを記録します。レシート ID とフィンガープリントを保持します。メッセージの識別子ごとに、現在確認済みのフィンガープリントを履歴レシートとは別に追跡します。ウィンドウキーのソースリビジョン世代により、A→B→A という復元は、元の A のリトライではなく新しい作業として扱われます。同一リビジョン内では、キーはチェックポイント／リトライをまたいで安定します。新規または復元されたメッセージは、適切な場合、同じ照合済みアイテムを更新します。新しい操作キーができたからといって、新しいエンティティを作成する理由にはなりません。書き込みが不確かな間にソースが変更された場合でも、再開したセッションを完了する前に、保持されているすべての保留中の計画を照合します。

フェーズ 5 — カーソルをチェックポイントに保存して報告する

readers/collector-state.mjs の純粋ヘルパーを使って、新しいカーソルスナップショットを作成します。これらのヘルパーが本番状態を書き込むことはありません。チェックポイントまたは完了処理の前には、必ずリーダーを通してセッションを再読み込みし、遷移ヘルパー経由で assertStable を使用して、変更されたソースや処理中のソースを拒否します。検証済みの各ウィンドウの後に checkpointWindow の進捗を保存し、読み戻します。部分的なセッションは完了ではありません。レシートを保持し、次に選択対象となったときに再開します。保留中のメッセージすべてとセッションのイベントスキャンが検証された後にのみ、completeSession を設定します。skipTrivial には、事実に即した理由が必要です。ID を一括で完了扱いにしたり、既存のマップ項目を削除したりしないでください。古いハイウォーターマークフィールドはすべて変更せずに維持します。新しい処理の完了によって、古い作業を隠すことはできません。

ホストごとに実行するコレクターは 1 つだけにしてください。保存の直前に本番カーソルを再読み込みし、開始時のスナップショットと比較します。並行して変更されていた場合は、上書きせずに停止して調整してください。保存されたカーソルとレポート全体をページ単位で取得して検証し、保持されたマップや来歴も確認します。その後、次の内容を報告します。

# Collection report — <ISO timestamp>
Sources: <tool: sessions found / processed / skipped-live>
Windows analyzed: N · budget used: <sessions>/<max>
Planted: topics N (new X, updated Y) · people N · events N · facts N · quotes N
Dropped: secrets-shaped values N · low-confidence extractions N
Cursor: resolved <IDs/revisions>; partial <IDs>; legacy high-water unchanged
Backlog: <eligible deferred count>; oldest discoverable <ID/date>; blocked <IDs/reasons>
Handoff: <n> new items awaiting the gardener's validate gate

Substrate の意味的な完了

このスキルを Substrate のランナーまたはワークフロージョブとして実行する場合、人が読める出力として収集レポートを残し、最後の空でないアシスタント行には SUBSTRATE_OUTCOME_V1= 宣言を 1 つだけ正確に記述します。ライフサイクルの完了は成功の指標ではありません。

すべての対象セッションが完全に処理されたか、誠実な理由でスキップされ、解決済みのリビジョンのみが完了扱いになり、登録した項目の来歴が保持され、利用可能なストアを通じてレポートとカーソルが保存され、読み戻された場合に限り、outcome: "succeeded" を宣言します。部分的なセッションは、検証済みの進捗と保留中の書き込みが保持され、再開地点として報告される場合にのみ許容されます。来歴の喪失、タイムスタンプによって未解決の作業を隠すこと、秘密情報の保存、または必須レポートの保存失敗は、outcome: "failed" となります。メモリストアへの書き込みは Git の変更ではないため、changes.status: "notApplicable" を使用します。

成功時の行の例（プレースホルダーを実際の根拠に置き換えてください）：

SUBSTRATE_OUTCOME_V1={"version":1,"outcome":"succeeded","summary":"Collected <n> sessions and persisted report <artifact-id>","evidence":{"changes":{"status":"notApplicable","reason":"Memory-store mutations are not Git changes"},"verification":{"status":"passed","commands":["read back collector cursor","read back report artifact <artifact-id>"]}}}

2 つ目の宣言を出力せず、その後には何も出力しないでください。Substrate ジョブ以外では、このプラットフォーム固有の行を追加しないでください。

定期実行

ガーデナーと同じホスティング方法です。このスキルを使ってエージェントを呼び出せるスケジューラーであれば、どれでも利用できます。適切な頻度は、コレクターを毎日実行し、その後にガーデナーを毎晩実行することです。そうすれば、各収集結果を 1 日以内に手入れできます。どちらも予算上限が設定されているため、最悪の場合でも「新しい情報はありません」というレポートになります。

来歴とクレジット

抽出パイプライン（スキャン → マッチ → 更新）、その保守的なデフォルト、3 つの説明規律、引用の合格基準、および prompts/ のプロンプトは、Jeremy Scherer（MIT、© 2026 Jeremy Scherer）による Flare576/ei を出典としています。EI は、このパイプラインを 5 つのコーディングツールに対するインポーターレイヤーとして実行します。このスキルはストレージ側を一般化し、memory-gardener と組み合わせています。