Wiki Query — Knowledge Retrieval

You are answering questions against a compiled Obsidian wiki, not raw source documents. The wiki contains pre-synthesized, cross-referenced knowledge.

This skill is READ-ONLY

wiki-query answers questions. It MUST NOT create or modify any wiki content. The ONLY write it may perform is the single Step 6 append to log.md.

Never, even when a change seems obviously helpful:

• create or edit pages under concepts/, entities/, skills/, references/, synthesis/, journal/, or projects/
• modify index.md, hot.md, _insights.md, or .manifest.json

If the user's message contains a new finding, an action request ("save this", "ban X", "record that"), or anything implying a change, do not perform it. Answer the question, PROPOSE the change, and route the user to the right skill:

• quick note / gotcha → wiki-capture --quick
• a full new page → wiki-capture
• a project-knowledge sync → wiki-update

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). For cross-project queries without @name, prefer the global config when present, even if it is a symlink to the vault .env. This gives OBSIDIAN_VAULT_PATH and any QMD variables. Works from any project directory.
2. Load QMD settings from the resolved config before deciding retrieval strategy. If QMD_WIKI_COLLECTION is set, treat QMD as available subject only to transport/tool checks below. If it is empty or unset, say briefly why QMD is being skipped before using grep/page reads.
3. If $OBSIDIAN_VAULT_PATH/hot.md exists, read it first — it gives you instant context on recent activity. If the user's question is about something ingested recently, hot.md may answer it before you even open index.md.
4. Read $OBSIDIAN_VAULT_PATH/index.md to understand the wiki's scope and structure

Visibility Filter (optional)

By default, all pages are returned regardless of visibility tags. This preserves existing behavior — nothing changes unless the user asks for it.

If the user's query includes phrases like "public only", "user-facing", "no internal content", "as a user would see it", or "exclude internal", activate filtered mode:

• Build a blocked tag set: {visibility/internal, visibility/pii}
• In the Index Pass (Step 2), skip any candidate whose frontmatter tags contain a blocked tag
• In Section/Full Read passes (Steps 3–4), do not read or cite any blocked page
• Synthesize the answer only from allowed pages — do not mention that excluded pages exist

Pages with no visibility/ tag, or tagged visibility/public, are always included.

In filtered mode, note the filter in the Step 6 log entry: mode=filtered.

Retrieval Protocol

Follow the Retrieval Primitives table in llm-wiki/SKILL.md. Reading is the dominant cost of this skill — use the cheapest primitive that answers the question and escalate only when it can't. Never jump straight to full-page reads.

Step 0: GraphRAG Pre-pass (fast index query — no page reads)

Before opening any pages, query the compiled graph index:

obsidian-wiki graph-query "$OBSIDIAN_VAULT_PATH" "<question>" --pretty

Output fields:

• answer_type: direct | path | list | gap | impact | bridges | hubs | clusters | surprising — shapes what to do next. The last five are structural intents: the question is about the shape of the vault, and the answer comes back fully computed in graph (see below) with no page reads at all.
• graph: present only for structural intents — the computed answer. null otherwise.
• candidates: top-ranked pages by title/tag/summary match + degree, with scores and summaries
• should_read: the pages most worth opening — start here instead of speculatively reading many files
• path: for multi-hop queries, the shortest wikilink path between the two concepts
• god_nodes_relevant: hub pages related to your query terms — always useful context
• index_only: if true, the top candidate's summary already answers the question — skip page reads
• temporal: as_of, retrievable, excluded_historical — how many pages the event-time filter held back (see below)

Structural intents — these are answered entirely from the graph. The user's phrasing routes automatically:

Report the graph payload directly — do not re-derive it by reading pages. If a structural question names a page that can't be resolved, the CLI falls back to direct and graph is null.

Decision tree:

1. If graph is non-null → the structural answer is complete. Report it and stop; no page reads.
2. If index_only: true → answer directly from candidates[0].summary. Skip Steps 1–4, go to Step 5.
3. If answer_type == "path" and path is non-empty → the connection is in path. Read only those pages.
4. Otherwise → open only should_read pages (not all candidates). This replaces the speculative 5–10 page reads the old flow required.

The graph used here excludes vault bookkeeping files (index.md, log.md, hot.md, _insights.md). They link to nearly every page, so including them made any two pages look ~2 hops apart and produced meaningless A → index → B paths.

Event time. Pages may carry valid_from / valid_until / superseded_by frontmatter. A page whose valid_until has passed is historical: it stays in the vault and in the graph, but drops out of candidates by default, so "which X do we use?" answers with what is true now rather than whatever was written first.

• When temporal.excluded_historical is non-zero, say so if it is material to the answer — the user may be asking about the superseded state.
• If the question is about the past ("what did we use in 2025", "before the migration"), re-run with --as-of YYYY-MM-DD to retrieve what held then.
• Use --include-historical when the user explicitly wants the whole history, or when you are tracing how a decision changed.
• A returned candidate carrying superseded_by names its replacement — follow it rather than reporting the stale claim as current.

obsidian-wiki graph-query "$OBSIDIAN_VAULT_PATH" "<question>" --as-of 2025-06-01 --pretty
obsidian-wiki graph-query "$OBSIDIAN_VAULT_PATH" "<question>" --include-historical --pretty

The structural intents ignore this filter on purpose: deleting a page still breaks the historical pages that link to it, so a blast radius must not shrink just because a dependent is no longer current.

Fallback (if obsidian-wiki is not installed): proceed with Step 1 as normal using grep and index.md.

Step 1: Understand the Question

Classify the query type:

• Factual lookup — "What is X?" → Find the relevant page(s)
• Relationship query — "How does X relate to Y?" / "What contradicts X?" → Find both pages, their cross-references, and their relationships: frontmatter blocks for typed edges
• Path / multi-hop query — "How is X connected to Y?" / "What links X to Y?" / "Trace the chain from X to Z" / "What does X depend on transitively?" → X and Y don't link directly; the connection runs through intermediate pages. Use the multi-hop graph traversal in Step 4b.
• Synthesis query — "What's the current thinking on X?" → Find all pages that touch X, synthesize
• Gap query — "What don't I know about X?" → Find what's missing, check open questions sections
• Challenge query — "challenge this" / "argue against X" / "poke holes in my plan" / "what did I decide about X?" → The user is about to commit to something. Look for the vault's own evidence against it. See "Challenge queries" under Step 5.

Also decide the mode:

• Index-only mode — triggered by "quick answer", "just scan", "don't read the pages", "fast lookup". Stops at Step 3. Answers from frontmatter + index.md only.
• Normal mode — the full tiered pipeline below.

Step 2: Index Pass (cheap)

Build a candidate set without opening any page bodies:

• You've already read index.md above — use it as the first filter. It lists every page with a one-line description and tags.
• Use Grep to scan page frontmatter only for title, tag, alias, and summary matches. A pattern like ^(title|tags|aliases|summary): scoped to vault .md files is far cheaper than content grep.
• Collect the top 5–10 candidate page paths ranked by:
  1. Exact title or alias match
  2. Tag match
  3. Summary field contains the query term
  4. index.md entry contains the query term
• Apply tier ordering within each rank bucket: when two candidates score equally, prefer tier: core over tier: supporting over tier: peripheral. Read the tier: frontmatter field with the same cheap grep as other fields. Pages without a tier: field are treated as supporting.

Track retrieval counts as you go (for the transparency report in Step 5/6):

• candidates_seen — total distinct pages that matched any rank criterion above, before trimming to the top 5–10.
• candidates_used — how many of those you actually carried forward into Steps 3/4.
• dropped — candidates_seen − candidates_used, i.e. matches that existed but were never read. If this is non-zero, name the dropped pages (or the count if there are many) so the user knows retrieval wasn't exhaustive — this is not an error, just an honest accounting of what was left out.

If you're in index-only mode, stop here. Answer from summary: fields, titles, and index.md descriptions only. Label the answer clearly: "(index-only answer — page bodies not read; facts below are from page summaries and may miss nuance)". Then skip to Step 5.

Step 2b: QMD Semantic Pass (optional — requires QMD_WIKI_COLLECTION in resolved config)

GUARD: If $QMD_WIKI_COLLECTION is empty or unset after config resolution, skip this entire step and proceed to Step 3. Mention the missing variable in your working update.

No QMD? Skip to Step 3 and use Grep directly on the vault. QMD is faster and concept-aware but the grep path is fully functional. See .env.example for setup.

If QMD_WIKI_COLLECTION is set, run QMD before reaching for Grep unless the question is already fully answered by hot.md or index.md metadata. QMD is especially preferred when the question is semantic, project-specific, asks for related context, or uses terms that may not appear verbatim in titles/frontmatter.

Choose the QMD transport from $QMD_TRANSPORT:

• mcp (default): use the QMD MCP tool configured in the agent.
• cli: run the local qmd CLI. Use $QMD_CLI if set; otherwise use qmd.

For detailed CLI command selection, maintenance, and VM caveats, use the local $qmd-cli skill when it is installed.

If the selected transport is unavailable (no MCP tool, qmd not on PATH, or the command errors), skip QMD and continue with Step 3.

For MCP transport:

mcp__qmd__query:
  collection: <QMD_WIKI_COLLECTION>   # e.g. "knowledge-base-wiki"
  intent: <the user's question>
  searches:
    - type: lex    # keyword match — good for exact names, file paths, error messages
      query: <key terms>
    - type: vec    # semantic match — good for concepts, patterns, "what is X like"
      query: <question rephrased as a description>

For CLI transport, pick the command from $QMD_CLI_SEARCH_MODE:

Keep operator-like or punctuation-heavy tokens such as no-sudo, ansible_become=false, and ~/.local/bin in the lex: line. Rewrite the vec: line as plain natural language without hyphenated -term words; QMD treats -term as negation, and negation is not supported in vec/hyde queries.

• quality (default): best relevance; slower on CPU.

  ${QMD_CLI:-qmd} query $'lex: <key terms>\nvec: <question rephrased as a description>' -c "$QMD_WIKI_COLLECTION" -n 8 --files

• balanced: hybrid search without LLM reranking; use when quality is too slow.

  ${QMD_CLI:-qmd} query $'lex: <key terms>\nvec: <question rephrased as a description>' -c "$QMD_WIKI_COLLECTION" -n 8 --no-rerank --files

• fast: semantic-only recall, or search instead when exact names, file paths, or error messages matter.

  ${QMD_CLI:-qmd} vsearch "<question rephrased as a description>" -c "$QMD_WIKI_COLLECTION" -n 8 --files

Use ${QMD_CLI:-qmd} get "#docid" to retrieve a ranked document by docid when CLI output provides one.

The returned snippets or ranked files act as pre-read section summaries. If they answer the question fully, skip Step 3 and go straight to Step 4 (reading only the pages QMD ranked highest). If not, use the ranked file list to guide which files to grep or read in Step 3.

Fold QMD hits into the same candidates_seen count from Step 2 (dedupe by path — a page found by both frontmatter grep and QMD counts once).

Defensive filter: drop any _raw/ path from wiki-collection results. The wiki collection is supposed to index only compiled pages, but a misconfigured collection (see .env.example) can end up indexing _raw/ — including stale drafts sitting in _raw/_archived/ that were already superseded by a promoted page. Before using a QMD hit from $QMD_WIKI_COLLECTION, check its path: if it contains _raw/, discard it from the wiki-collection result set (it may still surface legitimately via $QMD_PAPERS_COLLECTION, cited as a raw source). This keeps a misconfigured collection degrading to "missing recall" rather than "silently citing a superseded draft as compiled knowledge." If you see _raw/ paths coming back from the wiki collection, mention it in your working update so the user knows their collection scope needs fixing (see .env.example QMD section).

Also search papers when the question may have source material in _raw/:

If QMD_PAPERS_COLLECTION is set and the user is asking about a topic likely covered by ingested papers (research, theory, background), run a parallel search against the papers collection. Cite raw sources separately from compiled wiki pages in your answer.

Step 3: Section Pass (medium cost — only if Steps 2/2b are inconclusive)

For each of the top candidates, pull the relevant section without reading the whole page:

• Use Grep -A 10 -B 2 "<query-term>" <candidate-file> to get just the lines around the match.
• This usually returns 15–30 lines per hit instead of 100–500.
• If the section grep gives a clear answer, go straight to Step 5.

Step 4: Full Read (expensive — last resort)

Only when Steps 2 and 3 don't answer the question:

• Read the top 3 candidates in full. When choosing which 3 to read, apply tier ordering: read core pages before supporting, and skip peripheral pages unless they are the only match.
• Follow at most one hop of [[wikilinks]] from those pages if the answer requires cross-references.
• For relationship queries ("How does X relate to Y?" / "What contradicts X?"): also read the relationships: frontmatter block of the candidate pages. Each entry gives a typed, directional edge (extends, implements, contradicts, derived_from, uses, replaces, related_to). Surface these explicitly in your answer — "Page A contradicts Page B (typed edge)" is more useful than "Page A links to Page B".
• Check "Open Questions" sections for known gaps.
• If you're still short, then fall back to a broad content grep across the vault. Tell the user you escalated — this is the expensive path and they should know.

Step 4b: Multi-hop Graph Traversal (typed edges)

Plain retrieval surfaces pages that mention the query terms. It cannot answer path / multi-hop queries — "How is X connected to Y?", "What does X depend on transitively?", "Trace the chain from X to Z" — when X and Y never appear on the same page. The answer lives in the shape of the typed-edge graph, not in any single page body. This is the step that walks it.

Run this step only for path/multi-hop queries (or when a relationship query returns no direct edge between the two pages). It is built entirely from frontmatter — never read page bodies here.

1. Build the typed-edge adjacency (cheap). Grep every page's relationships: block in one pass — Grep -A 20 "^relationships:" <vault>/**/*.md (frontmatter only). Each entry yields a directed, typed edge source —type→ target. Add the reverse direction as a traversable edge too (mark it (reverse)), since "connected to" is symmetric even though the typed assertion is directional. Plain body [[wikilinks]] count as untyped related_to edges only if you need them to complete a path — prefer typed edges first.
2. Locate the endpoints. Resolve X (and Y, if the query names two) to page paths using the registry from Step 2. If an endpoint is ambiguous, pick the tier: core candidate and note the assumption.

3. Bounded BFS. If obsidian-wiki is installed, let the CLI do the walk over the wikilink graph first — it is exact and instant:

   obsidian-wiki graph-analyse "$OBSIDIAN_VAULT_PATH" --path "<X>" "<Y>"                  # two-endpoint: shortest chain + hop count
   obsidian-wiki graph-analyse "$OBSIDIAN_VAULT_PATH" --around "<X>" --depth 3 [--direction out|in]  # one-endpoint: reachable pages by hop

   --path follows links in either direction unless --direction out; --around --direction in answers "what depends on X" (its blast radius). Then decorate the returned chain with the typed edges from step 1 (the CLI sees [[wikilinks]], not relationship types). Otherwise, or to find alternate paths, walk manually:

   • Max depth 3 hops by default (the connection is rarely meaningful beyond that). Raise to 4 only if the user says "deep" / "however many hops it takes".
   • Frontier cap: stop expanding a node once the visited set exceeds ~60 pages — report partial results rather than fanning out across the whole vault.
   • For a two-endpoint query (X→Y): stop as soon as you find the shortest path; then continue briefly to surface up to 2 alternate paths if they exist.
   • For a one-endpoint query (X transitively): collect all nodes reachable within the depth limit, grouped by hop distance.

4. Report the path(s) with edge types. Show the chain, not just the endpoints — the typed edges are the answer:

   [[concepts/transformers]] —uses→ [[concepts/attention]] —derived_from→ [[concepts/rnn-seq2seq]] —contradicts (reverse)→ [[concepts/lstm]]

   State the hop count and whether any hop is a (reverse) traversal or an untyped related_to fallback (those chains are weaker — flag them). If no path exists within the depth limit, say so explicitly: "No typed-edge path from X to Y within 3 hops — they are in disconnected regions of the graph." That is itself a useful finding (a graph gap).

Cost guard: this step reads only frontmatter via grep. If the adjacency grep returns nothing (no page uses relationships: yet), report that the graph has no typed edges to traverse and suggest running cross-linker to populate them, then fall back to ordinary one-hop retrieval.

Step 5: Synthesize an Answer

Compose your answer from wiki content:

• Cite specific wiki pages using [[page-name]] notation
• Note which step the answer came from ("found in summary" vs "grepped section" vs "full page read") — helps the user understand confidence
• If the wiki has contradictions, present both sides
• If the wiki doesn't cover something, say so explicitly
• Suggest which sources might fill the gap

Page trust annotations: For every page cited in your answer, check its lifecycle frontmatter and compute is_stale = (today − updated) > 90 days. Annotate risky pages inline so the user knows which citations to verify:

Examples in a synthesized answer:

[[concept-page]] (stale: last updated 2026-01-15) — Original claim was X.
[[verified-page]] (VERIFIED but stale: last updated 2025-09-10) — Reader should reverify before relying.
[[disputed-page]] (DISPUTED, marked 2026-04-30: contradicted by [[new-source]]) — Earlier said Y, now uncertain.
[[old-page]] (ARCHIVED: superseded by [[new-page]]) — Use the successor.

Pages with no lifecycle field (legacy pages predating the schema) are treated the same as draft — annotate if stale, skip otherwise. Never fabricate a lifecycle_reason; if the field is absent, omit the reason from the annotation.

Surface the project source location (project-scoped queries). When the cited pages are project-scoped — their path is under projects/<name>/..., or their frontmatter carries a source_path/source_repo field — resolve where the actual code lives so a proposed fix can name real files and a follow-up turn can edit them:

1. Read $OBSIDIAN_VAULT_PATH/.manifest.json and look up .projects.<name>.source_repo — this is the authoritative, machine-independent identity (e.g. github.com/owner/name). It is what you report.
2. Resolve a local checkout root by trying these in order and stopping at the first that exists: .projects.<name>.source_cwd_hint (a ~-relative hint), then a legacy .projects.<name>.source_cwd (an absolute path, older manifests only), then the page's source_path frontmatter. Expand ~ in any candidate and confirm the directory actually exists before using it. A legacy absolute path is used only as a local convenience — never reported as the project's identity.

Report the Source code: line using source_repo. When a local checkout resolved in step 2, append the concrete path so the reader can act on it (e.g. <repo> — local checkout at ~/code/name/public/lib/anticheat.js). When the query implies a code fix is wanted and a local checkout exists, name the specific files to edit and offer to implement it as an explicit, separate next step — but never edit during the query itself (see the READ-ONLY guard above). If no local checkout resolves, report the repo and say the code is not checked out on this machine.

Challenge queries. The job is to argue with the user using their own notes, not to be agreeable. Run the normal retrieval on the idea's topic, then search further for:

• earlier decisions on the same question, especially ones that went the other way (synthesis/, projects/, pages with "decision", "decided", "chose", "rejected", "won't do");
• things that failed or were rolled back: post-mortems, "gotcha", "broke", "reverted", lifecycle: disputed or archived pages, contradicts relationships;
• open questions and constraints the idea would run into.

Lead the answer with the strongest counter-evidence, each point quoted or closely paraphrased with its [[page]] and date, e.g. "[[synthesis/rust-rewrite]] (2025-11-02) says the rewrite was abandoned over build times. What is different now?" Then list what the vault says in favour, if anything. End with one or two questions the user should answer before going ahead. If the vault holds nothing against the idea, say so plainly. Never invent an objection the notes don't support: an empty challenge is a useful answer.

Step 6: Log the Query

This is the only write this skill performs — do not edit anything else, and do not append to log.md by hand:

obsidian-wiki memory log QUERY \
  query="the user's question" result_pages=<N> \
  mode=<normal|index_only|filtered> escalated=<true|false> \
  candidates_seen=<N> candidates_used=<N> dropped=<N>

The command takes the memory lock and appends one parseable line; it never touches index.md or hot.md.

Use the counts tracked since Step 2. If a count wasn't tracked (e.g. index-only mode never built a full candidate set), write 0 rather than omitting the field — the log format should stay parseable.

Answer Format

Structure answers like this:

Based on the wiki:

[Your synthesized answer with [[wikilinks]] to source pages]

Pages consulted: [[page-a]], [[page-b]], [[page-c]]

Gaps: [What the wiki doesn't cover that might be relevant]

Retrieval: N candidates seen, M read, D dropped (untouched matches, if any: [[page-d]], [[page-e]])

Source code: <source_repo> (local checkout at ~/code/<name>) — to implement, the relevant files are …. (Say the word and I'll switch out of query mode to make the change.)

The Source code line is optional — include it only for project-scoped queries where you resolved a source_repo (see Step 5). Report the repository, not a machine absolute path; add the local checkout path only when it actually exists on this machine.

The Retrieval line is always included — it's the transparency report from the counts tracked since Step 2 (mirrors the candidates_seen/candidates_used/dropped fields logged in Step 6). In index-only mode, report the counts from the frontmatter scan; if D is 0, drop the parenthetical rather than writing an empty list.