Qa

QA Pack — "Ask the vault anything"

qa is the read layer of the Karpathy-style KB. It treats your compiled wiki as an always-available context store, pulls the relevant slices, answers, and files the result back so your own explorations accumulate in the vault.

Core principle

Every answer is a new note in outputs/. Never reply in chat-only. Reason: Karpathy's insight — "my own explorations and queries always 'add up' in the knowledge base." Chat-only answers evaporate.

Directory output

outputs/
  answers/                # one file per QA session
    -.md
  reports/                # curated / multi-step research
  briefs/                 # exec summaries

Commands

/ask — Single-question research

When the user invokes /ask :

1. Extract entities & concepts from the question. Use them as search seeds.
2. Search the wiki in this order (merge results, dedupe):

• obs search content "" --path compiled/ --json
• obs search content "" --path raw/ --json (deeper context)
• obs tags find for tag-based hits.
• obs links backlinks "" to follow the graph 1 hop.

1. Rank the top 10-20 notes by relevance (exact match > partial > tag match > backlink).
2. Read each note fully (concept pages preferred; raw as supporting).
3. Write the answer directly to outputs/answers/-.md with this structure:

```markdown --- title: type: answer question: askedat: sourcesused: tags: [output, answer, ] ---

#

## TL;DR

## Detailed answer

## Evidence map | Claim | Sources | |---|---| | | [[source-A]], [[source-B]] |

## What my vault does NOT cover

## Confidence

## Related notes

• [[]] — why related
• [[]] — why related

```

1. Link back: append a one-line backlink from each source concept page to the new answer under a ## Derived answers section (optional but recommended).
2. Report the file path, TL;DR, and "read the full answer at [[]]".

/deep — Multi-step research dive

When the user invokes /deep :

1. Generate 5-10 sub-questions that would collectively cover the topic.
2. Run /ask on each sub-question, chaining answers as context for the next.
3. Merge into a single outputs/reports/.md with sections per sub-question.
4. At the end, write a "Synthesis" section that ties threads together.
5. Add a "Further questions" list. Offer to /ingest each one as a future research target.

/compare — Compare 2+ concepts from the wiki

When the user invokes /compare [ ...]:

1. Load each concept's compiled/concepts/.md.
2. Pull supporting raw sources for each.
3. Build a comparison table: dimensions × concepts. Let the dimensions emerge from the material (don't hardcode).
4. Save to outputs/reports/compare--vs-.md.

/timeline — Build a timeline of events on a topic

When the user invokes /timeline :

1. Search sources; extract date-stamped events.
2. Normalize dates (approximate → quarterly buckets).
3. Build a markdown table or Mermaid gantt diagram.
4. Save to outputs/reports/timeline-.md.

/what-do-I-think — Pull together your own notes on a topic

When the user invokes /what-do-I-think :

1. Restrict search to notes with tag my-notes OR frontmatter author: me OR inside a user-designated "journal" folder.
2. Synthesize ONLY the user's own writing — exclude external-source material.
3. Output outputs/reports/my-take-.md with a "Evolution over time" section if timestamps support it.

Evidence discipline

Every factual claim in the answer must have an inline wikilink to its source. If a claim has no source, either:

• Mark it (inferred) and explain the inference, OR
• Remove it.

If the wiki is silent on the question, say so explicitly. Do not fill gaps from model priors without flagging: "Not in vault; pulled from general knowledge → consider /ingest to harden this."

Search fallback order

1. obs search against compiled/ (fastest, most curated).
2. obs search against raw/ (deeper, noisier).
3. obs links path for graph-based relevance.
4. Last resort: web search — and when used, /ingest the fetched source so future runs hit the vault first.

When to widen context

If initial hit set is ` to add a specific source.

• Run /deep instead of /ask.

Output hygiene

• Every output note gets tags: [output, answer|report|brief, ...] so lint and search can filter it.
• Outputs are never read back as sources by compile (avoid echo loops). The compile skill must ignore the outputs/ directory.

Related skills (same pack)

• [[ingest]] — feed new sources when the wiki is thin
• [[compile]] — must run before qa sees new raw material
• [[lint]] — checks that qa outputs cite sources
• [[render]] — convert qa answers to slides / briefs

Attribution

Pack inspired by Andrej Karpathy's KB workflow, which notes that at ~100-article scale, LLMs can answer complex questions against a wiki without needing vector RAG — the auto-maintained index and summaries are enough.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: markfive-proto
• Source: markfive-proto/obsidian-brain-vault
• License: MIT
• Homepage: https://supermarcus.ai/brain-os

Install and usage instructions live in the source repository linked above.