Wiki Quick Chat Capture
Capture non-obvious bugs, fixes, and gotchas from an agent chat into Obsidian `_raw/` drafts your wiki ingest pipeline can promote.
Overview
wiki-quick-chat-capture is an agent skill most often used in Build (also Operate, Grow) that formats Claude-session findings into Obsidian `_raw/` files ready for wiki-ingest promotion.
Install
npx skills add https://github.com/ar9av/obsidian-wiki --skill wiki-quick-chat-captureWhat is this skill?
- Writes `_raw/` files with vault-aligned frontmatter (title, tags, summary, lifecycle, provenance)
- Standard finding templates for bug/fix arcs and gotcha/API-quirk arcs with before/after code fences
- Designed for promotion by `/wiki-ingest` or `/data-ingest`—not a finished wiki page generator
- Captures session provenance (`capture_source: claude-session`) and confidence tiers for later curation
- Raw frontmatter includes tier, lifecycle, base_confidence, and provenance weights (extracted 0.85 / inferred 0.15)
- Summary field capped at ≤200 characters in frontmatter spec
Adoption & trust: 1 installs on skills.sh; 1.8k GitHub stars.
What problem does it solve?
You solved something important in chat but have no structured, vault-ready note your ingest pipeline can trust.
Who is it for?
Indie builders who run an Obsidian wiki with ingest skills and want session learnings captured while debugging or integrating.
Skip if: Teams that want auto-published docs without a vault taxonomy, lifecycle fields, or a follow-on ingest step.
When should I use this skill?
A Claude session produced a confirmed bug fix, gotcha, or API behavior worth promoting through your Obsidian ingest flow.
What do I get? / Deliverables
You get a draft `_raw/` file with frontmatter and a finding block that `/wiki-ingest` or `/data-ingest` can promote into durable wiki knowledge.
- One `_raw/` markdown file with YAML frontmatter and a finding or gotcha body block
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build → docs because the skill’s main output is structured knowledge artifacts tied to how you document what you shipped or learned while building. Subphase docs fits raw finding blocks, frontmatter, and promotion hooks (`wiki-ingest`, `data-ingest`) rather than runtime code or infra.
Where it fits
After fixing a third-party API quirk, capture behavior, workaround, and confirmation in a `_raw/` draft for the vault.
Turn a multi-step debugging thread into a structured finding with before/after code for your team wiki.
Log a production-only symptom and validated fix so the next incident search starts from promoted wiki pages.
Archive recurring user-facing gotchas as supporting-tier notes with provenance from support sessions.
How it compares
Use as a capture template for draft notes—not as a full documentation generator or search MCP.
Common Questions / FAQ
Who is wiki-quick-chat-capture for?
Solo and indie builders who maintain an Obsidian knowledge vault and want agent sessions to produce ingest-ready `_raw/` drafts instead of unstructured chat history.
When should I use wiki-quick-chat-capture?
During Build when you document integrations or fixes; in Operate when you record production gotchas; in Grow when you capture support patterns—always before running wiki-ingest on the finding.
Is wiki-quick-chat-capture safe to install?
It is documentation-format guidance; review the Security Audits panel on this Prism page and inspect what your agent is allowed to write to disk before enabling filesystem access.
SKILL.md
READMESKILL.md - Wiki Quick Chat Capture
# Raw File Format Reference Full specification for `_raw/` files written by `wiki-quick-chat-capture`. These files are designed to be promoted by `/wiki-ingest` or `/data-ingest`. ## Frontmatter ```yaml --- title: "<Descriptive cluster title>" category: skills tags: - topic/<primary-tech> - <1-3 additional domain tags from vault taxonomy> summary: "<1–2 sentences, ≤200 chars — what is this finding about?>" tier: supporting related: [] extends: null contradicts: null superseded_by: null capture_source: claude-session project: "<project name or null>" base_confidence: 0.75 lifecycle: draft lifecycle_changed: <YYYY-MM-DD> provenance: extracted: 0.85 inferred: 0.15 sources: - "<project> session (<YYYY-MM-DD>)" --- ``` ## Body: Finding Block For bugs and fixes: ```markdown ## <Finding Title> **Problem:** <what was non-obvious or broken — be specific about the symptom> **Root cause:** <why it happened — the underlying mechanism, not just the error message> **Fix:** ```<lang> // ❌ before // ✅ after ``` **Confirmed by:** <build pass / test pass / live app / error disappeared> ``` For gotchas and API quirks (no traditional bug/fix arc): ```markdown ## <Gotcha Title> **Behavior:** <what surprised the user> **Explanation:** <why it works this way> **Workaround / Pattern:** <what to do instead> **Confirmed by:** <how it was validated> ``` Omit sections that have nothing to say. Add a `**Notes:**` block at the end for caveats, related edge cases, or follow-up questions. --- ## Provenance + Confidence Calibration Apply provenance markers inline per the `llm-wiki` convention: | Marker | When to use | |---|---| | *(none)* | Explicitly stated in the conversation | | `^[inferred]` | Synthesized or generalized beyond what was directly said | | `^[ambiguous]` | Uncertain, potentially incomplete, or contradicted elsewhere | Use the table below to set `base_confidence` and the `provenance` split: | Evidence strength | `extracted` | `inferred` | `base_confidence` | |---|---|---|---| | Build error + test pass | 0.90 | 0.10 | 0.80–0.90 | | Fix applied, appeared to work | 0.75 | 0.25 | 0.70–0.75 | | Discussed, not fully confirmed | 0.60 | 0.40 | 0.60 | | Reasoned from a single case | 0.50 | 0.50 | 0.55 | `extracted + inferred` should sum to 1.0 (or include a small `ambiguous` fraction if applicable). --- ## Multiple Findings in One File When several related findings belong to the same topic cluster, place them sequentially in the body — each as its own finding block with a `##` heading. Use a short intro paragraph before the first block to explain what ties them together. ```markdown # Swift 6 Concurrency Gotchas Findings from migrating an iOS app to strict concurrency checking. All confirmed during the build phase. ## Actor reentrancy in async forEach **Problem:** ... ## MainActor isolation not inferred on @Observable **Problem:** ... ``` --- name: wiki-quick-chat-capture description: > Fast, zero-friction capture of technical findings from the current conversation to the wiki's _raw/ staging area. Use this skill when the user says "/wiki-quick-chat-capture", "quick capture", "capture this finding", "save this bug fix", "capture this gotcha", "drop this to raw", "quick save to wiki", or wants to capture a non-obvious discovery mid-session without a full wiki-ingest run. Writes one _raw/ file per topic cluster in under 60 seconds — no subagents, no QMD updates, no manifest writes. Run /wiki-ingest or /data-ingest later to promote raw files to proper wiki pages. compatibility: Requires ~/.obsidian-wiki/config or OBSIDIAN_VAULT_PATH env var. qmd CLI optional. metadata: version: "1.0" allowed-tools: Bash Read Write --- # Wiki Quick Chat Capture Extract reusable technical findings from the current conversation and stage them in `_raw/` for later promotion. The goal is zero-friction capture of discoveries that would otherwise be lost when the session ends. **Speed contract:** Inline only. No su