agentleFS
dexio-wikidexio-wiki/llm-wiki-skills/skills/wiki-capture/SKILL.md

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

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-Chen1999Skill

    claude-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-Chen1999Skill

    graph-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

  • nexuschainsSkill

    cross-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

  • nexuschainsSkill

    tag-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

  • bozhouDevSkill

    wiki-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

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
  1. Distinctive:

    Before the agent's context is compacted or the session is closed.

    line 23
  2. Distinctive:

    When a person says "remember this", "note that", or "put that in the wiki".

    line 24
  3. Distinctive:

    List candidates from the session: Only these kinds count:

    line 29
  4. Distinctive:

    Drop the rest: Leave out plans that were not decided, the agent's own guesses, task progress, anything already in the wiki, secret values, …

    line 35
  5. Distinctive:

    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 …

    line 47
  6. Distinctive:

    Keep it small. A typical session yields zero to five items.

    line 54
  7. Very specific:

    Keep a state file so each transcript is read once.

    line 64
  8. Distinctive:

    Read only the person's messages and the agent's final answers first.

    line 68
  9. Very specific:

    When several agents capture into one wiki, follow wiki-shared: search immediately before each write, because another agent may have filed …

    line 72

“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

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

  1. 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.
  2. 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.
  3. 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: follow wiki-conflicts (superseded when something changed, corrected when the page was wrong), which keeps a dated line of the old claim.
  4. 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").
  5. 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 lower confidence if the page carries one. A possible decision is never filed as a decision.
  6. 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:

  1. Find the transcripts. Claude Code keeps them as JSONL under ~/.claude/projects/<project>/; Hermes exports them with hermes sessions export; other agents document their own location.
  2. Keep a state file so each transcript is read once. Default: .wiki-state.json at the wiki root, listed in .gitignore (the checker reads only .md files), 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.
  3. 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.
  4. 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.
  5. 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.

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.