wiki-agent

Wiki Agent — エージェント間の履歴を対象を絞って検索・取り込み

特定の AI エージェントの生の会話履歴から、クエリ駆動で対象を絞って取り込みます。通常、ユーザーは現在、別のエージェントを使っていて、別のエージェントでの過去のセッションからコンテキストを取り込みたいと考えています。

これは一括取り込みではありません。特定のトピックに関するセッションを見つけ、関連するデータを抽出して Wiki にまとめ、ユーザーがすぐに行動に移せるよう、情報を統合した回答を返します。

コマンドの振り分け

呼び出しを解析して、対象のエージェントと任意のクエリを特定します。

コマンド	対象	例
/wiki-claude [query]	Claude Code の履歴	/wiki-claude "how did I set up auth middleware"
/wiki-codex [query]	Codex CLI の履歴	/wiki-codex "rust ownership patterns"
/wiki-hermes [query]	Hermes エージェントの履歴	/wiki-hermes "memory architecture"
/wiki-openclaw [query]	OpenClaw の履歴	/wiki-openclaw "project planning approach"
/wiki-copilot [query]	Copilot チャットの履歴	/wiki-copilot "test strategy for API routes"
/wiki-pi [query]	Pi エージェントの履歴	/wiki-pi "how did I refactor the auth module"

クエリが指定されていない場合は、デフォルトで最近のセッションモードになります。そのエージェントの未処理セッションから直近の 5 件を取り込み、見つかった内容の概要を返します。これは、そのエージェントのみを対象とした wiki-history-ingest に相当します。

開始前に

文体プロファイル： 自然言語の Markdown を作成または書き換える前に、llm-wiki/SKILL.md の Writing Profile Resolution セクションを読み、適用してください。フレームワークのスキーマ、出典、安全性、操作固有の要件を優先してください。 WRITING.md の設定は、新たに作成または書き換える自然言語の Markdown にのみ適用されます。ソースの内容と構造化レコードはそのまま保持してください。

1. 設定を解決する — llm-wiki/SKILL.md の Config Resolution Protocol に従います（インラインの @name による上書き → CWD から上位へ .env を検索 → グローバル設定 → セットアップの確認）。これにより OBSIDIAN_VAULT_PATH が得られます。
2. $OBSIDIAN_VAULT_PATH/.manifest.json を読み、すでに取り込まれている内容を確認します。
3. $OBSIDIAN_VAULT_PATH/hot.md が存在する場合は読み、Wiki の最近のアクティビティについてコンテキストを把握します。

---

ステップ 1：エージェントの履歴ルートを特定する

エージェント	デフォルトパス	設定による上書き
claude	~/.claude + ~/Library/Application Support/Claude/local-agent-mode-sessions/	.env の CLAUDE_HISTORY_PATH
codex	~/.codex	.env の CODEX_HISTORY_PATH
hermes	~/.hermes	環境変数または .env の HERMES_HOME
openclaw	~/.openclaw	.env の OPENCLAW_HOME
copilot	~/.copilot	.env の COPILOT_HISTORY_PATH
pi	~/.pi/agent/sessions	.env の PI_HISTORY_PATH

履歴ルートが存在しない場合は停止し、ユーザーに次のように伝えます。「<agent> の履歴が <path> に見つかりません。このマシンで <agent> を実行したことがありますか？.env で <CONFIG_VAR> を設定すると、カスタムパスを指定できます。」

---

ステップ 2：セッション一覧を作成する

エージェントごとに最もコストの低いインデックスソースを使用します。関連するセッションがわかるまでは、セッションファイルを開かないでください。

Claude

Primary index:   ~/.claude/projects/  (directories = projects, files = sessions)
Session files:   ~/.claude/projects/*/*.jsonl
Desktop index:   find ~/Library/Application Support/Claude/local-agent-mode-sessions -name "local_*.json"
Signal fields:   sessionId, cwd, startedAt, title (in local_*.json)

セッションの一覧を作成します：{path, project_dir, modified_at, already_ingested}。

Codex

Primary index:   ~/.codex/session_index.jsonl
Session files:   ~/.codex/sessions/**/rollout-*.jsonl
Signal fields:   thread_id, name/title, updated_at (in session_index.jsonl)

session_index.jsonl を読み、一覧として使用します。各行は {thread_id, name, updated_at} です。ディレクトリ名を照合して、スレッド ID とロールアウトファイルを対応づけます。

Hermes

Primary index:   ~/.hermes/memories/*.md  (fast to scan)
Session files:   ~/.hermes/sessions/**/*.jsonl
Signal fields:   file names, memory titles, first 3 lines of each memory

まずメモリファイル名をスキャンします（トピック名が付いていることがよくあります）。必要に応じて、セッション一覧を確認します。

OpenClaw

Primary index:   ~/.openclaw/workspace/memory/MEMORY.md  (structured long-term memory)
Daily notes:     ~/.openclaw/workspace/memory/YYYY-MM-DD.md
Session index:   ~/.openclaw/agents/*/sessions/sessions.json
Session files:   ~/.openclaw/agents/*/sessions/*.jsonl

まず MEMORY.md のセクションを読みます。これは全体を事前にまとめた要約です。日次ノートから最近の内容を把握します。

Copilot

Primary index:   session filenames / directory listing
Session files:   varies by client (VS Code: ~/.copilot/sessions/*.jsonl or similar)
Signal fields:   session timestamps, file names

Pi

Primary index:   ~/.pi/agent/sessions/--<cwd>--/ directories
Session files:   ~/.pi/agent/sessions/--<cwd>--/<timestamp>_<uuid>.jsonl
Signal fields:   cwd (decoded from dir name), session_info.name, timestamp in filename

まずセッションディレクトリをスキャンします。--<cwd>-- をデコードして作業ディレクトリを取得します。セッションヘッダーである 1 行目と、セッション名が含まれる session_info エントリがあれば読みます。独立したインデックスファイルはなく、ファイルシステムがインデックスです。

---

ステップ 3：クエリに照らしてセッションをスコアリングする

クエリが指定されている場合は、セッションの全ファイルを開かずに、インベントリ内の各セッションをスコアリングします。

1. 名前／タイトルの一致 — セッション名またはスレッドタイトルにクエリ語が含まれていますか？スコア：+3

2. CWD／プロジェクトの一致 — 作業ディレクトリから適切なプロジェクトだと判断できますか？スコア：+2

3. 新しさ — 90 日の半減期で指数関数的な時間減衰を適用します。減衰はマッチスコアに加算するボーナスではなく、乗数として適用します。

   base  = name_match(3) + cwd_match(2)
   score = base * (0.35 + 0.65 * 0.5 ** (age_days / 90))
   

   0.35 の下限を設けているのは意図的です。クエリに完全一致する古いセッションが、わずかに一致する最近のセッションよりも常に上位に来なければ、このスキルは「最初にどうやって解決したか」に答えられません。これは session-brain が使用する減衰と同じなので、2 つのスキルで一貫した順位付けができます。

4. 取り込み済みかどうか — このセッションが以前に取り込まれており、Wiki ページですでにクエリの内容を扱っている場合（hot.md と index.md を確認）、結果には表示したまま「網羅済み」とフラグを付けます

スコア順に上位 3～5 件のセッションを選択します。クエリが指定されていない場合は、未処理のセッションから新しい順に 5 件を選択します。

---

ステップ 4：関連する情報の塊を抽出する

選択した各セッションファイルを開き、クエリに関連する内容だけを抽出します。セッションが大きい場合は全体を読まず、対象を絞って抽出してください。

エージェントごとの抽出方法

Claude（JSONL 形式の会話）：

• 各行：{role, content, timestamp, ...}
• 次のコマンドで検索します：rg -i "<query terms>" <session.jsonl>。関連する行を探してください
• 抽出対象：各ヒットの前 10 行＋後 20 行の会話ウィンドウ
• 特別な手掛かり：ツール呼び出し（Read/Write/Bash/Edit）から実際に行われた作業が分かります。関連ウィンドウ内にあれば、キーワードに一致しなくても抽出してください

Codex（rollout JSONL）：

• 各行：{type: "session_meta|turn_context|event_msg|response_item", ...}
• type: "event_msg"（ユーザーのターン）と type: "response_item"（モデルの出力）に絞り込みます
• 次のコマンドで検索します：rg -i "<query terms>" <rollout.jsonl>
• 抽出対象：一致したターンと、その親コンテキスト（一致箇所の前にある turn_context）
• 除外対象：session_meta イベント（運用上のメタデータであり、知識ではありません）

Hermes（メモリファイル＋セッション JSONL）：

• メモリファイル：ファイル全体を読みます（短く、通常は各ファイル 500 語未満です）
• セッション JSONL：rg -i "<query terms>" と周辺ウィンドウを使用します
• タイトルが一致するメモリファイルは全体を読み、それ以外は grep のみで確認します

OpenClaw（MEMORY.md＋日次ノート＋セッション JSONL）：

• MEMORY.md：クエリ語を含むセクション見出しを grep し、そのセクションを抽出します
• 日次ノート：直近 30 日分からクエリ語を grep し、一致する段落を抽出します
• セッション JSONL：Claude と同じ grep ウィンドウ方式を使用します
• セッション JSONL より MEMORY.md／日次ノートを優先します（事前に要約されているためです）

Copilot（セッション JSONL）：

• Claude と同じ grep ウィンドウ方式を使用します
• 利用可能であれば、事前に要約されたチェックポイントファイルを探します

Pi（ツリー構造のレイアウトを持つ構造化 JSONL）：

• 各行はツリーエントリです：{type, id, parentId, timestamp, message?, ...}
• アクティブなブランチを構築します。エントリを id で対応付け、リーフ（子を持たない最後のエントリ）を見つけ、parentId をたどってルートまでさかのぼります
• 次のコマンドで検索します：rg -i "<query terms>" <session.jsonl>。一致するエントリを探してください
• 抽出対象：一致したエントリと、アクティブなブランチ上の祖先エントリ（親チェーンをたどります）
• 特別な手掛かり：アシスタントメッセージ内の toolCall ブロックから実際に行われた作業が分かります。関連ウィンドウ内にあれば、キーワードに一致しなくても抽出してください
• 利用可能であれば、事前に要約されている compaction および branch_summary エントリを優先します
• thinking コンテンツブロック（ノイズ）と model_change／thinking_level_change エントリは除外します

ステップ 5：情報の断片を Wiki ページにまとめる

抽出した情報の断片ごとに、Wiki のどこに配置するかを判断します。

1. Wiki ページがすでにこの内容を扱っているか確認する — index.md と各ページのフロントマターを grep して、トピックを確認します。すでに扱われている場合は、新しいページを作成せず、既存のページを更新します。
2. 標準ルール（llm-wiki/SKILL.md に記載）に基づいてカテゴリを決める：
   • テクニック／ハウツー → skills/
   • 抽象的な概念／パターン → concepts/
   • ツール／ライブラリ／人物 → entities/
   • 複数の領域にまたがる知見 → synthesis/
3. 必須のフロントマターを含めて、ページを作成または更新する：

   ---
   title: <topic>
   category: skill|concept|entity|synthesis
   tags: [tag1, tag2]
   sources: [<agent>://<path/to/session>]
   created: <date>
   updated: <date>
   confidence: high|medium|low
   lifecycle: stable|draft
   ---
   

   後から memory-bridge が見つけられるように、sources にエージェントのプレフィックスを設定します。
4. index.md で見つかった関連する Wiki ページへの相互リンクを追加します。

情報をまとめる際のルール（すべての取り込みスキルに共通）：

• 運用上のテレメトリではなく、長期的に有用な知識を抽出する
• 概念ごとに Wiki ページを 1 つ作成し、セッションごとには作成しない
• 重複させず、既存のページに統合する
• 重要な情報を残す：決定事項、見つかったパターン、有効だったテクニック、原因が判明したバグ

---

ステップ 6：統合した回答を返す

取り込み後、新たに取り込んだ Wiki コンテンツと既存の Wiki コンテンツをもとに、すぐに回答を統合して返します。

## From <agent> history: "<query>"

**Found in:** <N> sessions (<session names/titles>)

**Key insights:**
<Synthesized answer — 3–5 bullet points of the most useful knowledge>

**Wiki pages updated/created:**
- [[page-name]] — <what was added>
- [[page-name]] — <what was added>

**Sessions ingested:**
| Session | Date | Relevance |
|---------|------|-----------|
| <name>  | <date> | <one-line why it was selected> |

**Gaps:** <What the sessions didn't cover that might be relevant>

クエリが指定されているものの、関連するセッションが見つからなかった場合は、その旨を明確に伝えます：「<agent> の履歴に「」に関するセッションは見つかりませんでした。直近のセッションで扱ったトピック：<直近 3 件のセッションのトピック一覧>」

---

ステップ 7：追跡ファイルを更新する

処理したセッションファイルごとに .manifest.json を更新します。

{
  "<path>": {
    "ingested_at": "<now>",
    "source_type": "<agent>_conversation",
    "modified_at": "<file mtime>",
    "pages_created": [...],
    "pages_updated": [...]
  }
}

ロック付きの 1 回の呼び出しで、ログ、インデックス、ホットキャッシュを更新します。

obsidian-wiki memory sync WIKI-AGENT \
  agent=<agent> query="<query>" \
  sessions_searched=<N> sessions_ingested=<M> \
  pages_created=<X> pages_updated=<Y> \
  --takeaways "<one line: what was pulled in and what it changes>"

index.md、log.md、hot.md を手動で編集しないでください。このコマンドはロックを取得するため、並行して書き込む処理によって更新内容が失われるのを防げます。

手順の詳細は .skills/llm-wiki/references/MEMORY.md を参照してください。

---

エージェント間での利用パターン

このスキルが想定する主なユースケースは次のとおりです。

「Codex を使っています。X について Claude で何が分かりましたか？」 → /wiki-claude "X" — X に関する Claude のセッションを見つけて取り込み、回答を返します

「先週 Hermes でバグを解決しました。今すぐ Claude Code でそのコンテキストが必要です。」 → /wiki-hermes "bug description" — Hermes のセッションを表示して取り込みます

「すべてのツールで X について試したアプローチをすべて知りたいです。」 → /wiki-claude "X"、/wiki-codex "X"、/wiki-hermes "X" を順番に実行します。各コマンドが該当するセッションを取り込み、Wiki にエージェント間の全体像が蓄積されます。その後、/memory-bridge diff で各ツール独自の貢献内容を確認できます

クエリなし — 「最近の Codex での作業をまとめて」だけの場合 → /wiki-codex — 直近 5 件の Codex セッションを取り込み、概要を返します

「Claude Code を使っています。Pi で X について何が分かりましたか？」 → /wiki-pi "X" — X に関する Pi のセッションを見つけて取り込み、回答を返します

クエリなし — 「最近の Pi での作業をまとめて」だけの場合 → /wiki-pi — 直近 5 件の Pi セッションを取り込み、概要を返します

Vault への書き込み後の QMD 更新

QMD は検索インデックスであり、信頼できる唯一の情報源ではありません。$QMD_WIKI_COLLECTION が空または未設定の場合は、この手順をスキップします。このスキルが Vault の Markdown を書き込んだり書き換えたりした後にのみ実行してください。QMD の更新に失敗した場合は、Vault の変更をロールバックせず、QMD の状態を別途報告します。

$QMD_CLI が設定されている場合はそれを使用し、設定されていない場合は qmd を使用します。

${QMD_CLI:-qmd} update

出力にベクトルが必要である、または埋め込みが古い可能性があると示された場合は、次を実行します。

${QMD_CLI:-qmd} embed

次のいずれかの方法でコレクションを検証します。

${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"

または、特定のページパスが分かっている場合は、次を実行します。

${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5

次のいずれかを記録します。

• QMD refreshed: update + embed + verified
• QMD refreshed: update only + verified
• QMD skipped: QMD_WIKI_COLLECTION unset
• QMD skipped: qmd CLI unavailable
• QMD failed: <short error summary>