wiki-query

name

wiki-query

description

Answer a question from a hallouminate wiki with grounded, cited detail. Use when the user asks something the wiki should know — "what does the wiki say about X", "how does Y work here", "look it up in the wiki", "/wiki-query", or any factual question about a repo whose knowledge lives in a hallouminate corpus. Every claim in the answer carries a `path:line` citation back to the corpus. Do NOT use to write or update wiki entries (use wiki-ingest) or to bootstrap a new wiki (use wiki-init).

wiki-query — cited retrieval from a hallouminate wiki

Answer a question strictly from the wiki, with a citation on every claim. The model is a synthesizer over retrieved chunks, never a substitute for them. If the corpus does not support a claim, say so — do not fall back to training data.

Agent topology (required):

• Root = opus-tier (the strongest model the harness offers). Plans the retrieval, decides what's a distinct sub-question, synthesizes the final answer, and verifies every citation. Reasoning lives here.
• Fan-out = haiku-tier (the cheapest model). One sub-agent per sub-question. Each runs ground, reads the top chunks, and returns a compact cited evidence digest — never prose for the user. Retrieval noise stays in the sub-agent's context, not the root's.

The root NEVER answers from memory of the codebase. It answers from what the haiku digests bring back.

Flow

1. Plan (root / opus)

• Restate the question and name loaded assumptions in it.
• Decompose into 2–5 orthogonal sub-questions. One retrieval angle each — splitting "how does auth work and where are tokens stored" into two beats one blurry search. Single, narrow questions skip decomposition.
• Pick the corpus. If unspecified and >1 corpus exists, call list_corpora and ask which, or default to the repo's repo:{name}:wiki.
• Optionally list_tree once to see the wiki's shape — use it to phrase searches toward the right area (progressive disclosure: navigate the tree before reading leaves).

2. Fan out (haiku, parallel)

Spawn one haiku sub-agent per sub-question, in a single message so they run concurrently. Give each the exact ground call to make and this contract:

Run ground { query: "<sub-question>", corpus: "<corpus>", top_files: 5, chunks_per_file: 3 }. For each chunk that actually bears on the question, return a row: { claim, path, line_range, heading_path, score, snippet (≤200 chars) }, where path is the corpus-relative path. (ground keys its docs by absolute path; convert it to the corpus-relative path — the shape read_markdown takes, since it rejects absolute paths.) If ground returns nothing relevant, return { found: false } for that sub-question. Do NOT paraphrase beyond the snippet. Do NOT answer the user's question — you only gather evidence. If a top chunk is truncated and the answer hinges on it, read_markdown { corpus, path, line_numbers: true } (relative path) that one file and quote the exact numbered lines.

ground returns per file: summary, keywords, score, mtime, corpus, chunks[], and per chunk: heading_path (H1→leaf breadcrumb), line_range ([start,end], 1-based), score, snippet. That is the citation material — pass it up verbatim.

3. Synthesize (root / opus)

• Merge the haiku digests. Drop chunks below the relevance others clear; dedup overlapping spans.
• Write the answer lead-first: the direct answer, then supporting detail.
• Cite every claim inline as `path:start-end` (e.g. `architecture/dataflow.md:134-198`), optionally with the heading_path breadcrumb for navigation. A sentence with no citation is a bug — either find the chunk that backs it or cut it.
• Calibrate. Tag the overall answer certain (corpus directly states it), partial (corpus implies it / pieced from multiple chunks), or not in wiki (no supporting chunk — say this plainly, don't guess).
• If sub-questions came back found: false, list them as gaps — what the wiki doesn't cover yet (hand-off candidates for wiki-ingest).

4. Verify before answering

For each citation, confirm the cited line_range in that file actually contains the claim — read_markdown { …, line_numbers: true } the file if a claim is high-stakes or a snippet was truncated. The line_numbers flag returns the text with 1-based gutters, so you can confirm the exact path:line you're about to cite rather than counting by hand. Wrong citations are worse than no citations.

Output shape

**Answer** (<certain|partial|not in wiki>)
<lead-first synthesis, every claim carrying a `path:line` citation>

**Sources**
- `path:line` — <heading_path breadcrumb> — <one-line what it supports>

**Gaps** (omit if none)
- <sub-question the wiki couldn't answer>

Rules

• Ground every claim in a retrieved chunk. No chunk → no claim.
• The root reasons and synthesizes; haiku sub-agents retrieve. Never invert.
• Fan out sub-questions in one message so searches run in parallel.
• Prefer ground (hybrid lexical + vector + rerank) over guessing a filename.
• read_markdown to confirm exact lines before citing anything critical.
• Say "not in the wiki" out loud rather than answering from training data.
• Do not write to the corpus — this skill is read-only.