Save the current conversation as a permanent, structured wiki note. Use this skill when the user says "save this", "/wiki-capture", "capture this", "file this conversation", "preserve this", "add this to my wiki", or wants to turn what was just discussed into lasting knowledge. The skill classifies

Wiki Capture — Conversation to Wiki Note You are preserving knowledge from the current conversation as a permanent wiki note. The goal is to extract the substance — the knowledge itself — not a summary of what was said. Writing profile: Before drafting or rewriting natural language Markdown in any mode, read and apply the Writing Profile Resolution section in llm wiki/SKILL.md . Framework schema, provenance, safety, and operation specific requirements take precedence. WRITING.md preferences apply only to newly drafted or rewritten natural language Markdown; preserve source content and structured records. This skill has three modes: Full mode (default) — classify the content and write a finished, cross linked wiki page directly into the right category. This is the rest of this document (Steps 1–7). Quick mode ( quick ) — zero friction staging: drop findings to raw/ in under 60 seconds with no manifest/index/log/QMD writes. Used for mid session capture and by the session end Stop hook. See below, then stop — do not run the full mode steps. Correction mode ( correction ) — capture one atomic correction as derived knowledge while leaving the immutable conversation/source untouched. Use the template below, then update only the derived consumers and tracking links. Quick Mode ( quick ) Trigger when invoked as /wiki capture quick , by "quick capture" / "capture this finding" / "save this bug fix" / "save this gotcha" / "drop this to raw" / "quick save to wiki", or automatically by the session end Stop hook. Speed contract: Inline only. No subagents. No QMD. No manifest/ index.md / log.md / hot.md writes. Target: <60 seconds. Promotion to full wiki pages happens later via /wiki ingest . 1. Resolve config (Config Resolution Protocol in llm wiki/SKILL.md ): get OBSIDIAN VAULT PATH and OBSIDIAN RAW DIR (default: $OBSIDIAN VAULT PATH/ raw ). Ensure $OBSIDIAN RAW DIR exists; create it if not. Capture does not independently reinterpret validator schema inputs. When OBSIDIAN ALLOWED LIFECYCLES , OBSIDIAN ALLOWED RELATIONSHIP TYPES , OBSIDIAN REQUIRED TRUST FIELDS , or OBSIDIAN SCHEMA SOURCE is present, preserve it for the downstream lint/trust consumer: CLI values take precedence over environment/config values, which take precedence over framework defaults, and explicit blank or whitespace only values fail closed. Omit a variable to use defaults. 2. Gate — KEEP or SKIP? Before extracting, judge whether this session has capture value. This keeps the skill safe to call automatically without spamming raw/ . SKIP (exit with "Nothing worth capturing in this session.") if ALL are true: the conversation is purely conversational (planning/Q&A/explanation) with no implementation; no errors, debugging, or problem solving visible; nothing surprising or undocumented; every finding is already obvious from the docs. KEEP (proceed) if ANY are true: a fix or workaround was found through investigation; non obvious library/API/framework behavior was confirmed (edge case, undocumented constraint, time costing gotcha); a debugging session reached a concrete conclusion; a reusable pattern emerged. When invoked via the Stop hook, err toward SKIP — only KEEP on clear evidence. When invoked manually, err toward KEEP — the user called it for a reason. 3. Scan for reusable findings — non obvious bugs and root causes, framework/library gotchas, surprising API behavior, investigated workarounds, environment/toolchain quirks, patterns from debugging. Skip PM updates, config already in CLAUDE.md, inconclusive back and forth, anything obvious from the docs, and pleasantries. If nothing material emerged, say so and stop. 4. Cluster by topic — one raw/ file per topic cluster, not per finding. Name each as a kebab case slug (e.g. swift actor reentrancy , nextjs hydration mismatch ). 5. Infer project context from repo names, file paths, framework mentions, error messages. Use the most specific name you can reliably infer; else null . 6. Write raw files — for each cluster, write $OBSIDIAN RAW DIR/<ISO date <slug .md . Read references/RAW FORMAT.md for the full frontmatter spec, finding block body structure, and provenance/confidence calibration. Per cluster fields that vary: title , tags (2–4 from taxonomy), summary (≤200 chars), project (inferred or null ), base confidence (0.6 discussed → 0.75 fix applied → 0.9 test confirmed), provenance.extracted / provenance.inferred (sum to 1.0), lifecycle changed (today), sources ( "<project session (<YYYY MM DD )" ). 7. Confirm — list staged files and tell the user to run /wiki ingest to promote them: Quick mode deliberately does not write the manifest, index.md , log.md , hot.md , or refresh QMD — promotion via /wiki ingest handles all of that. Stop here; do not run the full mode steps below. Correction Mode ( correction ) Use this mode when a user or stronger authority corrects a claim derived from an immutable conversation, tool result, or other raw source. Never edit or copy the raw source. Resolve config, read the vault AGENTS.md , and update an existing derived page when one owns the claim; otherwise create the smallest owner compliant derived correction page. Record exactly one atomic claim pair. speaker type is semantic and must be assessed independently of a serialized message role (a tool result may be serialized as role=user ). Do not include raw transcript excerpts. Before any derived write, compute source pre sha256 directly from the immutable source and require it to equal source text sha256 . After writing the correction and updating derived consumers, recompute source post sha256 from the same locator. Abort and report an immutability violation unless source pre sha256 == source post sha256 == source text sha256 . This verification is mandatory even when the correction write succeeds. After writing the derived correction, link the immutable source to the created/updated page through .manifest.json , append only the correction ID and affected page counts to log.md , and propagate the atomic correction to every consumer independently. Mark a consumer complete only after verifying that consumer; do not collapse mixed results into a single aggregate status. Keep secrets, raw excerpts, and source copies out of the correction record. Full Mode Before You Start 1. 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 OBSIDIAN LINK FORMAT (default: wikilink ). 2. Read $OBSIDIAN VAULT PATH/index.md to understand existing wiki content (avoid duplicates) 3. Read $OBSIDIAN VAULT PATH/hot.md if it exists — it gives context on recent activity When writing internal links in Step 5, apply the link format from llm wiki/SKILL.md (Link Format section) using the OBSIDIAN LINK FORMAT value. Step 1: Identify What's Worth Preserving Scan the conversation. Ask: what knowledge emerged here that would be valuable in 3 months with no memory of this chat? Worth preserving: Decisions made and why they were made Analysis, frameworks, mental models developed Technical findings, patterns, or procedures Synthesized understanding of a topic Clear explanations of a concept that took effort to arrive at Key facts from an external source discussed in the conversation Skip: Logistics, scheduling, pleasantries Exploratory back and forth where no conclusion was reached Content that's already in the wiki If nothing material emerged, tell the user and stop. Step 2: Classify the Content Type Assign one of five types — this determines the target folder and tone: Type Description Target folder synthesis Multi step analysis or an answer to a specific question that required reasoning synthesis/ concept A definition, framework, or mental model (what a thing is ) concepts/ source Summary of an external document, article, or resource discussed references/ decision A strategic, architectural, or design choice and its rationale synthesis/ session A complete discussion summary when the conversation spans multiple topics journal/ If the content clearly belongs to a specific project (detected from context or user mention), place it under projects/<project name /<category / instead. Step 3: Rewrite as Declarative Knowledge Do not write a summary of the conversation. Write the knowledge itself, in declarative present tense: Not: "The user asked about X and Claude explained that..." Yes: "X works by..." Not: "We decided to use Y because..." Yes: "Y is preferred over Z because [reason]. [^[inferred] if the rationale was implied, not stated explicitly]" Apply provenance markers per llm wiki : Extracted — explicitly stated in the conversation (no marker) Inferred — generalized or synthesized from the conversation → ^[inferred] Ambiguous — disputed, uncertain, or contradictory → ^[ambiguous] Step 4: Generate a Slug and Title Derive a clear, descriptive title from the content. Slugify it: Lowercase, words separated by hyphens Max 50 characters Avoid dates in the slug (the frontmatter has created ) Step 5: Write the Wiki Note Create the file at the target path with required frontmatter: Body structure by type: synthesis / decision: concept: source: session: Every note must link to at least 2 existing wiki pages. Search index.md before writing. If fewer than 2 related pages exist, create minimal stubs for the most important concepts referenced. Step 5b: Update the Owner Profile and Todo Index The memory surface is only as good as what gets written into it. This is the step that keeps it alive — without it the profile stays empty and the session recap has nothing to inject. Durable facts about the person. If the conversation revealed something stable about how the user works — their stack, their conventions, their constraints, their timezone — record it: Apply the same KEEP/SKIP discipline as Step 1, and one extra rule that matters more: Only what the user actually told you , directly or by clear demonstration. Never infer a durable fact about a person from a document that was ingested — that is the document's content and belongs on a page, not in their profile. Stable, not incidental. "Uses Postgres" is a fact. "Ran a migration today" is an event; that belongs in the log. Time bound facts expire. "Has exams this weekend" or "travelling until the 20th" is worth carrying into the next few sessions, not forever. Record it with until YYYY MM DD (the last day it holds) and the recap stops injecting it once that date passes. Calibrate the confidence. Stated outright is ~0.9. Demonstrated repeatedly is ~0.75. Inferred from one session's behaviour is ~0.5 — and if you are below 0.5, do not write it at all. Correct, don't duplicate. profile set replaces an existing key, so updating a changed fact is the same command. Open threads. If the conversation left work unfinished, record it so the next session picks it up: Re adding an open thread with the same text touches it rather than duplicating, so this is safe to call when you are unsure whether it already exists. If the conversation closed a thread that is already listed, close it: Never close a thread the user did not actually finish. Staleness is reported by the tooling; it is not your job to tidy the list. In quick mode , do this step but skip Step 6 — profile and todo writes are cheap, locked, and are the whole point of capturing. Step 6: Update Tracking Files One locked call updates all three: Never hand edit index.md , log.md , or hot.md — see .skills/llm wiki/references/MEMORY.md .