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
- Ar9av/obsidian-wikiedited, first seen Nov 8, 2026
- wrg32786/aigent-ostheir own version, first seen Oct 13, 2026
- leninejunior/engrene-memory-bridgetheir own version, first seen Sep 19, 2026
- limsungjoo/codex-claude-memory-bridgetheir own version, first seen Aug 11, 2026
- jpoindexter/theft-kittheir own version, first seen May 20, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 1
- Ar9av/obsidian-wiki★ 3.7k94% same
Wrote their own version · 4
- wrg32786/aigent-os★ 25same name
- leninejunior/engrene-memory-bridge★ 12same name
- jpoindexter/theft-kit★ 1same name
- limsungjoo/codex-claude-memory-bridge★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository30 other files it gives its agents.
- claude-history-ingestSkill
- cross-linkerSkill
- daily-updateSkill
- graph-colorizeSkill
- hermes-history-ingestSkill
- impl-validatorSkill
- llm-wikiSkill
- skill-creatorSkill
- tag-taxonomySkill
- vault-skill-factorySkill
- wiki-agentSkill
- wiki-captureSkill
- wiki-context-packSkill
- wiki-dashboardSkill
- wiki-dedupSkill
- wiki-digestSkill
- wiki-exportSkill
- wiki-history-ingestSkill
- wiki-importSkill
- wiki-ingestSkill
- wiki-lintSkill
- wiki-querySkill
- wiki-rebuildSkill
- wiki-researchSkill
- wiki-setupSkill
- wiki-stage-commitSkill
- wiki-statusSkill
- wiki-switchSkill
- wiki-synthesizeSkill
- wiki-updateSkill
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
- Very specific: line 19
Read $OBSIDIAN_VAULT_PATH/.manifest.json — this is the source-of-truth for what tool produced what.
- Very specific: line 20
Read $OBSIDIAN_VAULT_PATH/index.md for page titles and one-line descriptions.
- Very specific: line 38
Read .manifest.json. For each source entry, extract:
- Very specific: line 84
Read frontmatter for the listed pages (grep for ^(title|category|tags|updated):) — do not read full page bodies unless the user asks.
- Distinctive: line 101
If no specific tools are given, compare all tools pairwise (limit to pairs with >0 overlap or unique pages to keep output concise).
- Very specific: line 136
After generating output, if the impl-validator skill is available in the current environment, spawn it as a subagent:
- Distinctive: line 160
Always show page counts so the user can calibrate how much knowledge is in each tool's silo.
- Very specific: line 161
Use [[wikilinks]] for page references (or standard Markdown links if OBSIDIAN_LINK_FORMAT=markdown is set).
- Very specific: line 163
If .manifest.json is empty or missing, say so clearly and suggest running /wiki-history-ingest first.
“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.
Files
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
- Resolve config — follow the Config Resolution Protocol in
llm-wiki/SKILL.md(inline@nameoverride → walk up CWD for.env→~/.llm-wiki/config→ prompt setup). This givesOBSIDIAN_VAULT_PATH. - Read
$OBSIDIAN_VAULT_PATH/.manifest.json— this is the source-of-truth for what tool produced what. - Read
$OBSIDIAN_VAULT_PATH/index.mdfor page titles and one-line descriptions.
Commands
Parse the user's invocation to determine mode:
| Invocation | Mode |
/memory-bridge <tool> | Browse — list all wiki pages sourced from <tool> |
/memory-bridge <tool> "<topic>" | Search — pages from <tool> that mention <topic> |
/memory-bridge diff | Diff — pages unique to each tool; overlap; blind spots |
/memory-bridge diff <tool-a> <tool-b> | Diff — compare two specific tools |
/memory-bridge map | Map — 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→claudecodex_rollout,codex_index,codex_history→codexhermes_memory,hermes_session→hermesopenclaw_memory,openclaw_daily_note,openclaw_session,openclaw_dreams→openclawcopilot_session,copilot_checkpoint,copilot_transcript,copilot_memory_artifact→copilotpi_session→pidocument→ingest- anything else →
manual
pages_createdandpages_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=NOutput 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 ifOBSIDIAN_LINK_FORMAT=markdownis set). - In diff mode, call out the most surprising asymmetry explicitly — that's the insight the user came for.
- If
.manifest.jsonis empty or missing, say so clearly and suggest running/wiki-history-ingestfirst.
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
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.

