query

name

query

description

Answer questions by searching an LLM wiki — a persistent, interlinked collection of markdown files that accumulates knowledge over time. Use this skill whenever the user asks something like "what does my wiki say about X", "ask my knowledge base about Y", "query my wiki", "what do I know about Z", "find what I've written about X", or any time they want to retrieve and synthesize information from a structured personal knowledge store. Also trigger this when a user is clearly working within an LLM wiki context (wiki/ directory, schema.md, index.md present) and asks a knowledge question, even if they don't explicitly say "wiki" or "query".

Query

Query answers a question by reading the wiki — not by guessing or drawing on general knowledge, but by finding relevant pages, synthesizing what they say, and citing sources. The goal is an answer that's grounded in the specific, curated knowledge the user has built up.

A good query response is more useful than a raw LLM answer because it's based on the user's actual notes, their specific context, and the relationships they've built — not just whatever was in training data.

Wiki location

Look for the wiki in this order:

1. A path the user explicitly specifies
2. A wiki/ subdirectory in the current working directory
3. The current working directory itself (if it looks like a wiki — has index.md or log.md)

If no wiki is found, tell the user and suggest running Ingest to start building one.

Query workflow

1. Orient via index.md

Read index.md first. This gives you the map — what pages exist, what categories they fall into, how the wiki is organized. From this, identify which pages are most likely to contain relevant information.

Also read schema.md if it exists, to understand the page types and how knowledge is structured.

2. Read relevant pages

Load the pages most likely to address the question. Cast a wide net initially — it's better to read one extra page than to miss the key one. As you read, follow [[wikilinks]] to related pages that seem relevant.

Typical reading depth:

• Start with the most directly relevant pages
• Follow 1–2 levels of wikilinks if the topic is interrelated
• If index.md suggests a synthesis/topic page exists, read it — it's usually the most useful starting point for cross-cutting questions

3. Synthesize and answer

Construct an answer that:

• Directly addresses the question
• Draws specifically on what the wiki contains (not general knowledge)
• Cites the pages you're drawing from: "According to [[source-slug]], ..." or inline citations like ([[entity-name]])
• Notes where the wiki is silent or uncertain — don't fill gaps with guesses

If the wiki contains contradictory information on the topic, surface the contradiction rather than picking one side arbitrarily. Flag it as something the Lint skill could help resolve.

4. Optionally persist the answer

If the answer synthesizes information in a way that would be valuable to future queries — especially if it required reading many pages and assembling a new picture — offer to save it as a new wiki page. Good candidates:

• A question the user is likely to ask again
• A synthesis that doesn't exist anywhere in the wiki yet
• A comparison across multiple entities or sources

Ask: "This answer pulls together several pages — want me to save it to the wiki?"

If yes, create the page, add it to index.md, and append to log.md:

## [YYYY-MM-DD] Query persisted: <question or topic>
- Created: [[new-page-slug]]
- Drew from: [[page-1]], [[page-2]], [[page-3]]

What "citing the wiki" looks like

Good:

Based on [[transformer-architecture]], the attention mechanism scales quadratically with sequence length. [[scaling-laws]] suggests this becomes the dominant cost past ~4K tokens.

Not as good:

The attention mechanism scales quadratically (this is well-known).

The first form is useful because the user can follow the links to check the source and see the fuller context. The second form is just a generic LLM answer that happens to live inside the wiki system.

When the wiki doesn't have the answer

Say so clearly. Don't fabricate. You might:

• Note which pages exist that are adjacent to the topic
• Suggest what source to ingest that would fill the gap (if you have a sense of what the user is working on)
• Offer to do a web search and then ingest the result (if web tools are available)

A wiki that accurately says "I don't know" is more trustworthy than one that confidently confabulates.