agentleFS
chobizzychobizzy/llm-wiki/skills/memory-bridge/SKILL.md

memory-bridge

Skill3 starsChanged 11 days agoMITView on GitHub

Browse and compare wiki knowledge by which AI tool originally produced it. Use this skill when the user says "/memory-bridge", "browse codex memory", "what did codex know about X", "show me claude knowledge", "cross-tool memory", "what does hermes know that claude doesn't", "show me knowledge from <tool>", "compare my AI tool memories", or wants to explore knowledge gaps between tools. Works from any project. Diff mode ("what's different", "unique to codex", "gaps between tools") is the killer feature — it surfaces blind spots between tools that the user may not know exist.

  • Reads credentials

5 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 2 are distinctive, and 7 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read $OBSIDIAN_VAULT_PATH/.manifest.json — this is the source-of-truth for what tool produced what.

    line 19
  2. Very specific:

    Read $OBSIDIAN_VAULT_PATH/index.md for page titles and one-line descriptions.

    line 20
  3. Very specific:

    Read .manifest.json. For each source entry, extract:

    line 38
  4. Very specific:

    Read frontmatter for the listed pages (grep for ^(title|category|tags|updated):) — do not read full page bodies unless the user asks.

    line 84
  5. Distinctive:

    If no specific tools are given, compare all tools pairwise (limit to pairs with >0 overlap or unique pages to keep output concise).

    line 101
  6. Very specific:

    After generating output, if the impl-validator skill is available in the current environment, spawn it as a subagent:

    line 136
  7. Distinctive:

    Always show page counts so the user can calibrate how much knowledge is in each tool's silo.

    line 160
  8. Very specific:

    Use [[wikilinks]] for page references (or standard Markdown links if OBSIDIAN_LINK_FORMAT=markdown is set).

    line 161
  9. Very specific:

    If .manifest.json is empty or missing, say so clearly and suggest running /wiki-history-ingest first.

    line 163

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Memory Bridge — Cross-Tool Knowledge Browser

You are helping the user browse and compare their Obsidian wiki knowledge filtered by which AI tool originally produced it. The wiki tracks source provenance in .manifest.json and page sources: frontmatter — this skill surfaces that metadata as a navigable view.

Before You Start

  1. Resolve config — follow the Config Resolution Protocol in llm-wiki/SKILL.md (inline @name override → walk up CWD for .env → ~/.llm-wiki/config → prompt setup). This gives OBSIDIAN_VAULT_PATH.
  2. Read $OBSIDIAN_VAULT_PATH/.manifest.json — this is the source-of-truth for what tool produced what.
  3. Read $OBSIDIAN_VAULT_PATH/index.md for page titles and one-line descriptions.

Commands

Parse the user's invocation to determine mode:

InvocationMode
/memory-bridge <tool>Browse — list all wiki pages sourced from <tool>
/memory-bridge <tool> "<topic>"Search — pages from <tool> that mention <topic>
/memory-bridge diffDiff — pages unique to each tool; overlap; blind spots
/memory-bridge diff <tool-a> <tool-b>Diff — compare two specific tools
/memory-bridge mapMap — full origin matrix: every page × every tool that touched it

Recognized tool names: claude, codex, hermes, openclaw, copilot, pi, manual (hand-written), ingest (wiki-ingest documents).

Step 1: Build the Source Map

Read .manifest.json. For each source entry, extract:

  • source_type — maps to tool name:
    • claude_conversation, claude_memory, claude_audit_log, claude_desktop_session → claude
    • codex_rollout, codex_index, codex_history → codex
    • hermes_memory, hermes_session → hermes
    • openclaw_memory, openclaw_daily_note, openclaw_session, openclaw_dreams → openclaw
    • copilot_session, copilot_checkpoint, copilot_transcript, copilot_memory_artifact → copilot
    • pi_session → pi
    • document → ingest
    • anything else → manual
  • pages_created and pages_updated — the wiki pages that came out of this source

Build a map:

tool_pages = {
  "claude": set(pages created/updated by claude sources),
  "codex":  set(pages created/updated by codex sources),
  ...
}

A page can appear in multiple tools' sets if multiple tools contributed to it.

Step 2: Execute the Mode

Browse Mode

Filter tool_pages[<tool>] and present as a grouped list:

## Knowledge from <tool> (<N> pages)

### By category (one line per folder in the vault's CATEGORIES table)
- references/ — N pages
- entities/   — N pages
- concepts/   — N pages
...

### Pages
| Page | Category | Tags | Last updated |
|------|----------|------|--------------|
| [[page-name]] | concept | tag1, tag2 | 2026-04-10 |
...

Read frontmatter for the listed pages (grep for ^(title|category|tags|updated):) — do not read full page bodies unless the user asks.

Search Mode

Within the filtered page set, run:

grep -l "<topic>" <pages in tool set>

Then grep section headers (^##) around matches to give context without full reads. Present results as a ranked list with the matching excerpt.

Diff Mode

Compute:

  • only_in_a = tool_pages[a] − tool_pages[b]
  • only_in_b = tool_pages[b] − tool_pages[a]
  • shared = tool_pages[a] ∩ tool_pages[b]

If no specific tools are given, compare all tools pairwise (limit to pairs with >0 overlap or unique pages to keep output concise).

Present:

## Memory Bridge Diff — <tool-a> vs <tool-b>

### Only in <tool-a> (<N> pages)
These concepts exist in your wiki from <tool-a> sessions but <tool-b> has never touched them.
<list with one-line descriptions from index.md>

### Only in <tool-b> (<N> pages)
<list>

### Shared (<N> pages)
Both tools have contributed to these pages.
<list — only show if ≤15; otherwise just the count>

### Notable gaps
<highlight the most interesting asymmetries — e.g. "codex has 12 pages on build tooling that claude has never seen">

Map Mode

Build a matrix showing every page and which tools have touched it. Cap at 50 rows; sort by number of contributing tools descending (most cross-tool pages first — these are the richest nodes).

| Page | claude | codex | hermes | copilot | pi |
|------|--------|-------|--------|---------|----|
| [[react-patterns]] | ✓ | ✓ | — | ✓ | — |
| [[rust-ownership]] | — | ✓ | — | — | ✓ |

Step 3: Spawn impl-validator (if available)

After generating output, if the impl-validator skill is available in the current environment, spawn it as a subagent:

impl-validator check:
  goal: "Browse/diff wiki knowledge by source tool and surface cross-tool blind spots"
  artifacts: [the output you just generated]
  checks:
    - Did you correctly parse source_type from .manifest.json?
    - Are page counts plausible (not 0 unless vault is empty)?
    - Is the diff symmetric (a−b and b−a are disjoint)?
    - Did you avoid reading full page bodies when not needed?

Apply any issues it surfaces before presenting output to the user.

Step 4: Log

Append to $OBSIDIAN_VAULT_PATH/log.md:

- [TIMESTAMP] MEMORY-BRIDGE mode=<browse|search|diff|map> tool=<tool> pages_shown=N

Output Conventions

  • Always show page counts so the user can calibrate how much knowledge is in each tool's silo.
  • Use [[wikilinks]] for page references (or standard Markdown links if OBSIDIAN_LINK_FORMAT=markdown is set).
  • In diff mode, call out the most surprising asymmetry explicitly — that's the insight the user came for.
  • If .manifest.json is empty or missing, say so clearly and suggest running /wiki-history-ingest first.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.