wiki-capture
Skill1 starsChanged 47 days agoMITView on GitHub
Capture what an agent session settled into an LLM wiki before it is lost: at the end of a task or session (or over saved transcripts), pick out decisions, verified facts, corrections and working procedures, drop the chatter, and file each item on the page that owns it. Use when a session or task ends, before context is compacted, when a person says to remember something, or on a schedule over past agent sessions (Claude Code, Codex, Hermes, OpenClaw).
5 other projects use a version of this.
Adopted by
Most recently taken up by
- Ar9av/obsidian-wikitheir own version, first seen Nov 8, 2026
- chobizzy/llm-wikitheir own version, first seen Nov 1, 2026
- VladTheProgrammer/claude-asimovtheir own version, first seen Oct 8, 2026
- Ivy-Chen1999/llm-wiki-kittheir own version, first seen Jun 23, 2026
- jehrhardt/agentstheir own version, first seen May 16, 2026
Used with
Projects with it also use claude-history-ingest, graph-colorize and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Ivy-Chen1999Skillclaude-history-ingest
Ingest Claude Code conversation history into the Obsidian wiki. Use this skill when the user wants to mine their past Claude conversations for knowledge, import their ~/.claude folder, extract insights from previous coding sessions, or says things like "process my Claude history", "add my conversations to the wiki", "what have I discussed with Claude before". Also triggers when the user mentions their .claude folder, Claude projects, session data, past conversation logs, local-agent-mode sessions, or audit logs.
Also in 3 projects that use this
Ivy-Chen1999Skillgraph-colorize
Color-code the Obsidian graph view by rewriting `.obsidian/graph.json` colorGroups. Use this skill when the user says "color my graph", "color code obsidian", "colorize the graph", "color the graph by tag", "color by category", "highlight visibility in graph", "make the graph colorful", "distinguish tags in graph", or wants nodes in Obsidian's graph view tinted by tag, folder, or visibility. Generates a `colorGroups` array from the vault's actual tags/categories and merges it into the existing graph.json without clobbering other graph settings. Always backs up first.
Also in 3 projects that use this
nexuschainsSkillcross-linker
Scans the wiki vault and adds missing [[wikilinks]] between pages that are related but not yet connected. Use this skill when the operator says "link my pages", "find missing links", "cross-reference the wiki", "connect my wiki", "add wikilinks", or after any large ingest to weave new pages into the existing knowledge graph. Also trigger when orphaned pages need connecting or when wiki-lint reports fragmented tag clusters. This is a write-heavy skill — it modifies page files to insert links, unlike wiki-lint which only reports.
Also in 3 projects that use this
nexuschainsSkilltag-taxonomy
Enforces and normalizes tags across the wiki against the controlled vocabulary in wiki/schema/tag-taxonomy.md. Use this skill when the operator says "fix my tags", "normalize tags", "tag audit", "clean up tags", "tag taxonomy", or "my tags are a mess". Also use when creating or updating wiki pages and the right tags are unclear. Operates in three modes: Audit (report current state), Normalize (apply fixes), and Classify (tag a single new page). Always reads the taxonomy file before assigning any tags.
Also in 3 projects that use this
bozhouDevSkillwiki-update
Use when revising existing wiki pages because knowledge has changed, a new piece of information updates or contradicts existing content, or the user wants to directly edit wiki content with LLM assistance.
Also in 3 projects that use this
- +5 more from Ivy-Chen1999
- +1 more from nexuschains
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- Ar9av/obsidian-wiki★ 3.7ksame name
- Ivy-Chen1999/llm-wiki-kit★ 21same name
- chobizzy/llm-wiki★ 3same name
- jehrhardt/agents★ 1same name
- VladTheProgrammer/claude-asimov★ 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 repository11 other files it gives its agents.
- wiki-conflictsSkill
- wiki-ingestSkill
- wiki-lintSkill
- wiki-orientSkill
- wiki-querySkill
- wiki-recordSkill
- wiki-refactorSkill
- wiki-reviewSkill
- wiki-setupSkill
- wiki-sharedSkill
- wiki-verifySkill
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 7 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 5 edited versions we read keep these.
7
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 23
Before the agent's context is compacted or the session is closed.
- Distinctive: line 24
When a person says "remember this", "note that", or "put that in the wiki".
- Distinctive: line 29
List candidates from the session: Only these kinds count:
- Distinctive: line 35
Drop the rest: Leave out plans that were not decided, the agent's own guesses, task progress, anything already in the wiki, secret values, …
- Distinctive: line 47
Ask rather than guess: If something might be a decision but nobody said so, or a fact rests on the agent's reading alone, ask the person in …
- Distinctive: line 54
Keep it small. A typical session yields zero to five items.
- Very specific: line 64
Keep a state file so each transcript is read once.
- Distinctive: line 68
Read only the person's messages and the agent's final answers first.
- Very specific: line 72
When several agents capture into one wiki, follow wiki-shared: search immediately before each write, because another agent may have filed …
“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
Capture a session into the wiki
Most of what a wiki should hold is decided in conversations: a person picks an option, an agent verifies a number, a procedure finally works on the third try. If nobody files it when the session ends, it is gone, and the next agent rediscovers it or, worse, guesses. Capture is the habit that keeps the wiki fed.
It is also where most wiki noise comes from. The goal is the few things that will matter again, not a summary of the session.
When
- At the end of any task that changed what is known or decided.
- Before the agent's context is compacted or the session is closed.
- When a person says "remember this", "note that", or "put that in the wiki".
- On a schedule, over saved transcripts, to catch sessions that ended without a capture.
Steps
- List candidates from the session. Only these kinds count:
- Decisions a person made, with their words, the date, and the reason if given.
- Facts verified during the session, with where they were verified.
- Corrections: anything the session showed the wiki gets wrong. These come first.
- Procedures that worked, including the step that failed before it worked.
- Preferences or constraints a person stated that will apply again.
- Drop the rest. Leave out plans that were not decided, the agent's own guesses, task progress, anything already in the wiki, secret values, and anything private a person has not cleared for everyone who reads the wiki. An agent proposing something and nobody objecting is not a decision. Where a credential is kept is worth filing; the value never is.
- Check each survivor against the wiki (
wiki-orient, search step). Already recorded: skip it. If the session showed the page is wrong or out of date, do not just overwrite it: followwiki-conflicts(superseded when something changed, corrected when the page was wrong), which keeps a dated line of the old claim. - File each item with
wiki-record: on the page that owns it, smallest edit, dated, sourced. The source is the session: who said or verified it, and when ("Dana in chat, 2026-09-28"; "checked on the vendor pricing page, 2026-09-28"). - Ask rather than guess. If something might be a decision but nobody said so, or a fact
rests on the agent's reading alone, ask the person in one line before filing it. If they
are not there, leave it out, or file it labelled
(unverified: <why>)and lowerconfidenceif the page carries one. A possible decision is never filed as a decision. - Report what you filed, one line per item with the page path, and what you skipped on purpose if a person might expect it to be there.
Keep it small. A typical session yields zero to five items. If you find fifteen, you are summarizing, not capturing.
Capturing from saved transcripts
For sessions that ended without a capture:
- Find the transcripts. Claude Code keeps them as JSONL under
~/.claude/projects/<project>/; Hermes exports them withhermes sessions export; other agents document their own location. - Keep a state file so each transcript is read once. Default:
.wiki-state.jsonat the wiki root, listed in.gitignore(the checker reads only.mdfiles), holding{"capture": {"done": ["<transcript path or session id>", ...]}}. On a hosted wiki keep it in the agent's own workspace. Never keep run state in a page. - Read only the person's messages and the agent's final answers first. Tool output is long and mostly noise; open it only to confirm a fact you intend to file.
- Apply the steps above. Items from old sessions need extra care: check them against the current wiki and, for anything mutable, against the source, since they may have changed.
- When several agents capture into one wiki, follow
wiki-shared: search immediately before each write, because another agent may have filed the same item minutes ago. Treat the wiki as shared if the schema says so, the history shows more than one writer, or you cannot tell.
Pitfalls
- Filing a transcript or a session summary as a page. Nobody reads them, and they bury the real pages in search results.
- Recording the agent's suggestion as the person's decision.
- Capturing the same fact on three pages. One page owns it; the others link to it.
- Waiting for the end of a very long session. Capture after each settled decision if the session is long enough that early context may be compacted.
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.

