Recover the forces that shaped code from historical evidence. Separate documented intent from supported inference, plausible hypotheses, and unknowns.

Code is evidence of mechanics, not motivation. Motivation may live in source history, reviews, tickets, documents, team discussions, incidents, telemetry, or product data.

Identify:

Use open files, recent edits, and conversation context to interpret a vague referent. State the interpretation so the user can redirect it. Ask only when different interpretations would require materially different investigations.

Treat the user's suggested explanation as a hypothesis to test.

Complete when: the target and question are precise enough to define relevant evidence.

Record the relevant paths and lines, key symbols, last-touch commits, earlier history through renames, and linked reviews or tickets. Useful starting commands include:

git blame -L <start>,<end> <file>
git log --follow -p -- <file>
git log --oneline -20 -- <file>
git log -1 --format=%B <commit>

Use an available forge client or API to read review descriptions and discussion. Do not assume a particular forge or tool is installed.

Capture paths, symbols, commits, review IDs, ticket IDs, dates, authors, and search terms for reuse across sources.

Complete when: an investigator can search another system without rediscovering what code and time window the question concerns.

Discover the repository and external read-only connectors available in the current runtime. Create one ledger entry per connector, then map each entry to an evidence category:

Read references/source-playbook.md, then load only the playbook for each available category. Tool names and schemas come from the runtime, not this skill.

Search every available connector by default, including multiple connectors in one category when they hold distinct records. Mark each ledger entry , , , or , with a reason and scope. A category may be inapplicable only when the target cannot enter it by construction.

Complete when: every discovered connector has a search plan or a specific status reason, and all seven categories appear in the ledger even when no connector is available.

Search connectors concurrently when independent read-only agents are available; otherwise search them sequentially. Use one bounded lane per connector, combining connectors only when they expose the same records and query vocabulary. The method must not depend on a particular agent provider, model, or runner configuration.

Use references/investigator-prompt.md as the lane contract. Pass the question, code anchor, category playbook, and any cross-cutting incident angle. Investigators gather evidence rather than answer the question.

For each source:

A null result becomes useful evidence only when the search that produced it is documented.

Complete when: every planned category returns cited evidence, a documented null result, or a named access gap.

Read references/epistemics.md and references/synthesizer-prompt.md. Synthesize directly or delegate to one read-only synthesizer with access to all findings and the code anchor.

Classify each claim:

Spot-check citations before presenting them. Surface contradictions instead of resolving them for narrative neatness. Preserve confidence language during any final edit.

Complete when: every rationale claim has a confidence tier, tier-appropriate phrasing, and adjacent evidence or an explicit gap.

Use this structure, omitting only sections that truly have no content:

For each source, state what was searched and what was found, including null results and skip reasons. A reader should be able to verify a cited claim quickly and judge the investigation's coverage.

When the investigation precedes a code change, add a concise constraint set:

Complete when: the answer distinguishes knowledge from inference, exposes the search boundary, and leaves the user with verifiable evidence rather than a plausible story.