Download .skills/claude-history-ingest/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does claude-history-ingest live?
The publisher keeps it at https://github.com/Ar9av/obsidian-wiki.
Which agents can use claude-history-ingest?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.
>
name: claude-history-ingest
description: >
Ingest Claude Code conversation/session history into Obsidian as distilled knowledge. Use for importing or mining past Claude sessions, .claude data, project/session history, or audit logs.
Claude History Ingest — Conversation Mining
You are extracting knowledge from the user's past Claude Code conversations and distilling it into the Obsidian wiki. Conversations are rich but messy — your job is to find the signal and compile it.
This skill can be invoked directly or via the wiki-history-ingest router (/wiki-history-ingest claude).
Before You Start
Writing profile: Before drafting or rewriting natural-language Markdown, read and apply the Writing Profile Resolution section in llm-wiki/SKILL.md. Framework schema, provenance, safety, and operation-specific requirements take precedence.
preferences apply only to newly drafted or rewritten natural-language Markdown; preserve source content and structured records.
WRITING.md
Resolve config — follow the Config Resolution Protocol in llm-wiki/SKILL.md (inline @name override → walk up CWD for .env → global config → prompt setup). This gives OBSIDIAN_VAULT_PATH and CLAUDE_HISTORY_PATH (defaults to ~/.claude)
Read .manifest.json at the vault root to check what's already been ingested
Read index.md at the vault root to know what the wiki already contains
Project Scoping — read WIKI_SKIP_PROJECTS from config (comma-separated substrings). Exclude any project directory whose name contains one of them from every step below (scan, delta, sampling, manifest writes). If the user names extra projects to skip this run, add them. Apply the exclusion once, uniformly — don't hand-write grep -v filters into individual commands, which drifts between the scan and manifest steps.
Ingest Modes
Append Mode (default)
Check .manifest.json for each source file (conversation JSONL, memory file). Only process:
Files not in the manifest (new conversations, new memory files, new projects)
Files whose modification time is newer than their ingested_at in the manifest
This is usually what you want — the user ran a few new sessions and wants to capture the delta.
Portable keys when comparing. Manifest keys follow the source key contract (v2) in llm-wiki/SKILL.md → .manifest.json. A session under $HOME is keyed ~-relative (~/.claude/projects/.../abc.jsonl), never by the expanded machine path; vault-relative and pseudo-keys are the other two forms. Before deciding a file is "new", resolve the stored key the same way the tool does (expand ~/env vars, resolve vault-relative against the vault root) — otherwise an already-tracked file looks new and gets re-ingested. The scripts/manifest.py helper does this for you:
# New/modified sources, honoring WIKI_SKIP_PROJECTS + --skip:
python3 "$OBSIDIAN_WIKI_REPO/scripts/manifest.py" delta "$OBSIDIAN_VAULT_PATH" \
--scan "$CLAUDE_HISTORY_PATH/projects/*/memory/*.md"
# One-time repair if the manifest still holds legacy absolute keys:
python3 "$OBSIDIAN_WIKI_REPO/scripts/manifest.py" migrate "$OBSIDIAN_VAULT_PATH" --dry-run
The helper is optional — if it's unavailable, apply the same resolution inline before every manifest lookup and write.
Pre-extraction (recommended — run before ingest)
Raw JSONL files are 80-90% noise: tool_use blocks, thinking blocks, progress events, and
file-history-snapshot entries dominate by byte count. The scripts/extract-jsonl.py helper
strips all of that and writes compact signal-only JSON to ~/.claude/extracted/, achieving
50–200× file-size reduction (e.g. 12 MB JSONL → 64 KB extracted). This lets the skill read
5–10× more conversations per run within the same token budget.
Run it as a pre-step before invoking this skill:
# First run — extract everything (skip excluded projects)
python3 "$OBSIDIAN_WIKI_REPO/scripts/extract-jsonl.py" --skip tsg,autom8
# Incremental — only sessions modified in the last day
python3 "$OBSIDIAN_WIKI_REPO/scripts/extract-jsonl.py" \
--since "$(date -v-1d +%Y-%m-%d)" --skip tsg,autom8
Extracted files live at ~/.claude/extracted/<project-dir>/<session-id>.json and contain:
When Step 3 reads conversations, always prefer the extracted file over the raw JSONL. (See Step 3.)
If extract-jsonl.py was not run first, fall back to raw JSONL — but note the coverage will be
shallower because each raw file costs far more tokens to read.
Conversation Sampling Heuristic
A history path can hold hundreds of conversation JSONLs — do not try to read them all. Per project:
If the project already has memory files (memory/*.md), ingest those first (they are
pre-distilled signal), then also process conversations not yet in the manifest — new
conversations should still be captured even for memory-rich projects.
If the project has no memory files, read only the 3 most recent conversations (by mtime)
to characterize it. Prefer pre-extracted files (see above) — they are cheap enough that you can
read 5–10 in the same token budget as 1 raw JSONL.
Always report what you sampled vs skipped (e.g. "agenttower: 7 memory files + 4 new conversations
ingested, 14 unchanged conversations skipped"), so the coverage gap is visible rather than silent.
Full Mode
Process everything regardless of manifest. Use after a wiki-rebuild or if the user explicitly asks.
Claude Code Data Layout
Claude Code stores data in two locations. Scan both.
Session metadata (local_<uuid>.json) — JSON file with fields like sessionId, cwd, startedAt, model, title. Read this first to understand the session context before opening the transcript.
Audit log (audit.jsonl) — Each line is a JSON record of one agent action: tool calls (Read, Write, Bash, Edit), file accesses, shell commands executed, MCP calls. Useful for understanding what the agent actually did — often richer signal than the conversation text alone. Fields: type, toolName, input, output, timestamp, sessionId.
Conversation transcript (.claude/projects/.../<uuid>.jsonl) — Identical format to CLI conversation JSONL. Parse the same way as ~/.claude/projects/*/*.jsonl.
Key data sources ranked by value (both locations combined):
Conversation JSONL (both ~/.claude/projects/*/*.jsonl and desktop app transcripts) — Full conversation transcripts. Rich but noisy.
Audit logs (audit.jsonl in desktop sessions) — Tool-call level record of what was done. Useful for extracting concrete actions, file patterns, and command patterns even when the conversation is sparse.
Session metadata (sessions/*.json and local_*.json) — Tells you which project, when, and what CWD.
Step 1: Survey and Compute Delta
Scan both data locations and compare against .manifest.json:
user type → feeds into an entity page about the user, or concept pages about their domain
feedback type → feeds into skills pages (workflow patterns, what works, what doesn't)
project type → feeds into entity pages for the project
reference type → feeds into reference pages pointing to external resources
The MEMORY.md index file in each project is a quick summary — read it first to decide which individual memory files are worth reading in full.
Step 3: Parse Conversation JSONL
Always check for a pre-extracted file first (see Pre-extraction section above). For each
conversation ~/.claude/projects/<proj>/<uuid>.jsonl, look for its counterpart at
~/.claude/extracted/<proj>/<uuid>.json. If found, read that instead — it is already filtered to
user + assistant text turns and costs 50–200× fewer tokens than the raw JSONL.
# Resolution order for each session:
1. ~/.claude/extracted/<project>/<session-id>.json ← prefer (compact, signal-only)
2. ~/.claude/projects/<project>/<session-id>.jsonl ← fallback (raw, noisy)
Reading a pre-extracted file: it already contains only the turns you need. Iterate
turns[].{role, text} directly. The top-level fields (cwd, start_ts, n_user_words, etc.)
give you project context without any further parsing.
Reading raw JSONL (fallback): Each line is a JSON object:
File access patterns — which files does the agent repeatedly Read or Edit? These are the high-value files in the project. Note them as project references.
Shell commands — recurring Bash commands reveal the project's build/test/deploy workflow. Distill these into a skills/ page (e.g. "how this project is built and tested").
Tool call sequences — if the agent always does Read → Edit → Bash in a particular order, that's a workflow pattern worth capturing.
Error patterns — failed tool calls (non-zero exit codes, error outputs) reveal pain points, known rough edges, or recurring bugs.
MCP tool calls — calls to MCP tools reveal which external services and APIs the project integrates with.
Skip from audit logs:
Routine file reads with no pattern (e.g. reading config files once)
Tool outputs that are just noise (long stack traces, verbose logs) — summarize the error class, not the full output
Anything that looks like secrets, tokens, or credentials in command arguments or outputs
Cross-reference with the conversation transcript: The audit log tells you what happened; the conversation tells you why. When both are available for the same session, use them together — the audit log grounds the conversation in concrete actions.
Read the paired local_<uuid>.json session metadata before processing the audit log — it gives you cwd, startedAt, and title to contextualize the actions.
Step 4: Cluster by Topic
Don't create one wiki page per conversation. Instead:
Group extracted knowledge by topic across conversations
A single conversation about "debugging auth + setting up CI" → two separate topics
Three conversations across different days about "React performance" → one merged topic
The project directory name gives you a natural first-level grouping
Step 5: Distill into Wiki Pages
Each Claude project maps to a project directory in the vault. The project directory name from ~/.claude/projects/ encodes the original path — decode it to get a clean project name:
For each project with content, create or update the project overview page at projects/<name>/<name>.md — named after the project, not _project.md. Obsidian's graph view uses the filename as the node label, so _project.md makes every project show up as _project in the graph. Naming it <name>.md gives each project a distinct, readable node name.
Important: Distill the knowledge, not the conversation. Don't write "In a conversation on March 15, the user asked about X." Write the knowledge itself, with the conversation as a source attribution.
Write a summary: frontmatter field on every new/updated page — 1–2 sentences, ≤200 chars, answering "what is this page about?" for a reader who hasn't opened it. wiki-query's cheap retrieval path reads this field to avoid opening page bodies.
Add confidence and lifecycle fields to every new page's frontmatter:
base_confidence: 0.42
lifecycle: draft
lifecycle_changed: <obsidian-wiki memory now --date>
On update, leave lifecycle and lifecycle_changed unchanged — only a human editor transitions lifecycle state.
Mark provenance per the convention in llm-wiki (Provenance Markers section):
Memory files are mostly extracted — the user wrote them by hand and they're already distilled. Treat memory-derived claims as extracted unless you're stitching together claims from multiple memory files.
Conversation distillation is mostly inferred. You're synthesizing a coherent claim from many turns of dialogue, often filling in implicit reasoning. Apply ^[inferred] liberally to synthesized patterns, generalizations across sessions, and "what the user really meant" interpretations.
Use ^[ambiguous] when the user changed their mind across sessions or when assistant and user contradicted each other and the resolution is unclear.
Write a provenance: frontmatter block on every new/updated page summarizing the rough mix.
Step 6: Update Manifest, Journal, and Special Files
Update .manifest.json
For each source file processed, add/update its entry with:
ingested_at, size_bytes, modified_at
source_type: one of "claude_conversation", "claude_memory", "claude_audit_log", "claude_desktop_session"
Update index.md, log.md, and hot.md with one locked call:
obsidian-wiki memory sync CLAUDE_HISTORY_INGEST \
projects=<projects> conversations=<conversations> \
desktop_sessions=<desktop_sessions> audit_logs=<audit_logs> \
pages_updated=<pages_updated> pages_created=<pages_created> \
mode=<mode> \
--takeaways "Ingested 5 Claude conversations across 2 projects; surfaced patterns in API design and testing strategy."
Never hand-edit index.md, log.md, or hot.md — the command takes the lock that keeps a parallel writer from dropping your update. --takeaways is the one-line conceptual summary that used to go in Recent Activity;
omit it to leave the previous takeaways untouched.
If an ongoing project is now better understood, record the thread so the next
session picks it up: obsidian-wiki memory todo add "<thread>" --origin projects/<name>.md.
See .skills/llm-wiki/references/MEMORY.md for the full procedure.
Privacy
Distill and synthesize — don't copy raw conversation text verbatim
Skip anything that looks like secrets, API keys, passwords, tokens
If you encounter personal/sensitive content, ask the user before including it
The user's conversations may reference other people — be thoughtful about what goes in the wiki
Reference
See references/claude-data-format.md for more details on the data structures.
QMD Refresh After Vault Writes
QMD is a search index, not the source of truth. If $QMD_WIKI_COLLECTION is empty or unset, skip this step. Run it only after this skill has written or rewritten vault markdown. If QMD refresh fails, do not roll back the vault changes; report the QMD status separately.
Use $QMD_CLI if set; otherwise use qmd.
${QMD_CLI:-qmd} update
If the output says vectors are needed or embeddings may be stale, run:
${QMD_CLI:-qmd} embed
Verify the collection with either:
${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"
or, when a specific page path is known:
${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5
Record one of:
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>
How do I install claude-history-ingest?
Download .skills/claude-history-ingest/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does claude-history-ingest live?
The publisher keeps it at https://github.com/Ar9av/obsidian-wiki.
Which agents can use claude-history-ingest?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.