Code is mechanics, not motivation: what it does is readable, why it exists lives in the record — commits, PRs, tickets, docs, chat, and telemetry, all partial and sometimes contradictory. Answer what shaped the code from that record, and say where the record runs out.

1. Fix the question

The target is the code the question is about: a chunk of code, a pattern, or a named design decision. When it is vague, take it from conversation context (open files, recent edits, what was just discussed), state your reading in one line, and proceed.

A question that carries its own answer ("I assume it's for performance?") supplies a hypothesis. Note it beside the question as one candidate for the synthesizer to test.

Done when the target and the question are written down, one line each, with the hypothesis beside them when the question carries one.

2. Map coverage

List the MCP servers in this session (the mcp__<server>__ tool prefixes) and assign each to one of seven sources: source control (always covered, by git and gh), tickets, documents, chat, observability, errors, analytics. A server that fits two takes the one matching its primary evidence: a product-analytics server that also tracks errors is analytics, a monitoring server that also holds incident records is observability. A server that holds no historical record — a browser, a filesystem, a worktree tool — takes none. Record the result as the coverage map.

Done when the coverage map marks every source covered (a server, or git and gh for source control) or skipped with a one-line skip reason: no server present, or ruled out for this target (a build-time script has no error tracking). A source you merely doubt is covered.

3. Anchor

Dispatch the anchorer (model: sonnet). The prompt carries: the path to references/anchor.md, which gives the git and gh invocations and what to record in each section; the target; the question, with its hypothesis. Done when every section of the anchor has returned filled and defensive reads yes or no.