Wiki Capture

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:

   Staged to _raw/:
     _raw/2026-05-27-swift-actor-reentrancy.md   — "Actor reentrancy causes deadlock in async forEach"
   Run /wiki-ingest to promote these to full wiki pages.

   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.

correction_id: <stable-id>
source_locator: <immutable file:line or channel/thread/timestamp>
source_text_sha256: <64 lowercase hex chars>
serialized_role: <source role, if present>
speaker_type: user | assistant | teammate | tool_result | slack_member
original_claim:
  subject: <exact entity or capability>
  assertion: <single atomic value>
corrected_claim:
  subject: <same exact entity or capability>
  assertion: <single atomic value or null>
authority_class: contract | decision | code | test | deploy | runtime | db | narrative
verification_state: verified | inferred | unverified | contradicted
asserted_at: <ISO-8601 timestamp>
effective_at: <ISO-8601 timestamp or null>
as_of: <ISO-8601 timestamp>
supersedes: [<original-claim-id>]
consumer_propagation:
  kw: open | not_applicable | complete
  ob: open | not_applicable | complete
  requirements: open | not_applicable | complete
  code: open | not_applicable | complete
  tests: open | not_applicable | complete
  ai_memory: open | not_applicable | complete
corrected_at: <ISO-8601 timestamp>

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:

If the content clearly belongs to a specific project (detected from context or user mention), place it under projects/<project-name>/<category>/ instead.