investigate · git:20260817.7b6963e · 2026-08-17 · sha256 60863ff35c242c25

investigate git:20260817.7b6963eA

Immutable. This exact content never changes and is served at /api/v1/blob/60863ff35c242c25.

---
name: investigate
description: Investigation flow. Takes a question about the system (why does X happen, where does Y live, is Z feasible, what broke) and returns a verified written answer with evidence. Read-only end to end, no branch, no code change, no pull request. Use when asked to investigate, diagnose, explain behaviour or assess feasibility, or on /investigate <question>.
---

# investigate: question in, verified answer out

Read-only, end to end. If the fix becomes obvious mid-flight, the finding
becomes the spec for the task funnel; you do not edit files here. An
investigation that quietly turns into a change skips triage, tests and review,
which is every gate the funnel has.

Input: the question after the command. Empty, ask what to investigate and stop.

## Stage 1 · Sharpen the question

Restate the question and state **what evidence would settle it**. If you cannot
say what would settle it, ask and stop. Fanning out on a vague question buys file
dumps, not an answer.

## Stage 2 · Fan out, read-only, in parallel, in one message

Each subagent gets the full question, because it inherits nothing, plus one
angle:

- **code path**, where it lives, who calls it, what it returns
- **data**, schema, migrations, what the rows actually allow
- **history**, `git log` and `git blame`, the tracker, why it is the way it is
- **runtime**, config, environment, scheduled jobs, webhooks, external services

Skip the angles the question obviously does not touch. Two is a normal number,
and the concurrency ceiling is `kit config get .maxParallelAgents`.

Every claim a subagent returns is tagged **MEASURED**, with the command and its
output, or **INFERRED**.

## Stage 3 · Verify

An INFERRED claim that bears on the conclusion is measured before the report:
run, or dispatch, the one command that would prove it. Two angles disagreeing is
resolved by measuring, never by picking the more plausible one. An inherited
claim is not a fact.

## Stage 4 · Deliver

- The answer in short prose, conclusion first, evidence after it.
- Tied to an existing issue, post it as a comment on that issue, in the
  language the rest of the tracker uses.
- Out-of-scope findings discovered along the way become new issues, the way the
  repo's pipeline document says to open them. Never code.
- If the fix is then asked for, hand the finding to the task funnel as its spec.

## Token rules

- No worktree and no dependency install. Nothing here writes, so nothing here
  installs.
- You hold conclusions, not file dumps. Subagents read, you consolidate.
- One MEASURED claim beats a paragraph of maybes. The command's output is
  cheaper than a wrong conclusion re-litigated across the session.