/investigate

name: investigate
description: >
  Evidence-based investigation of issues, bugs, API calls, integrations, and other aspects of software development that
  need a deep dive to find the root cause and solutions. Use when you need to debug, troubleshoot, diagnose, or figure
  out why something is broken. Does not review code for quality or style — use code-review for auditing changes or
  post-code-review-to-pr for posting review feedback to GitHub. Does not assess architectural health or structural risk
  — use architectural-analysis for architectural concerns. Does not research open-ended options, prior art, or how
  something works when nothing is broken — use research for that. Does not plan the structural change a root cause
  calls for — use plan-a-change. Does not map bounded contexts or domain boundaries — use ddd-analysis. Does not
  capture feedback on Han's own skills — use han-feedback for that.
argument-hint: "[symptom or problem description, and optionally an output path]"
allowed-tools: Read, Glob, Grep, Agent, Bash(bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh")

Project Context

• CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
• project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
• personal config directory: !`bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"`
• project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""`

As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md` probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

Investigation Approach

• Trace backward from symptoms — don't guess, follow the code.
• Launch parallel `han-core:evidence-based-investigator` agents for different angles simultaneously — one for the error

path, one for the data flow, one for recent changes.

• Add one or more specialist analysts **in parallel with** the investigators when the bug type calls for it

(concurrency, data flow across boundaries, database or query behavior). Specialist analysts find root causes generalists miss.

• The `han-core:adversarial-validator` agent handles all three validation strategies (challenge evidence, challenge fix,

challenge assumptions) internally.

• Apply the evidence rule from [../../references/evidence-rule.md](../../references/evidence-rule.md) to every finding.

Codebase findings (file path, line number, log line, test output) carry the trust-class label "codebase" and stand on their citation. Web-source context (RFCs, vendor docs, Stack Overflow, blog posts) carries the trust-class label "web" and is subject to the corroboration gate when it drives the proposed fix. When the investigation hits a point where no evidence at any tier resolves a question, label the no-evidence state rather than guessing.

• Lazy-create the output sections. Include a section in the plan file only when the investigation produced meaningful

content for it; omit any section that would be empty, and keep the sections that remain in the template's order. Never emit a heading with placeholder or "N/A" content.

• Invoke `han-communication:readability-guidance` to source the shared readability standard into your context, then

apply it as you write the findings, holding the named audience: the engineer who will implement the fix and may be paged on the bug. Scope that frame per section so the technical specifics the engineer needs (function names, exact failing conditions, file:line citations) are preserved, never simplified away.

Investigate

Step 1: Research and Investigation

Always dispatch

Launch at least 2 `han-core:evidence-based-investigator` agents in parallel, each investigating from a different angle — for example, one tracing the error path and another following the data flow.

Conditional specialist dispatch

Classify the bug from the user's symptom description before launching. Skip any specialist that does not apply. Dispatch every applicable specialist in parallel with the `han-core:evidence-based-investigator` agents in the same message.

1. **Launch han-core:concurrency-analyst** — when the symptom involves intermittent failures, race conditions, deadlocks, ordering issues, stale reads after writes, timeouts, dropped messages, or anything that only reproduces under load or concurrent users. Prompt: "Investigate the concurrency and async behavior of the code paths implicated by this symptom: {symptom}. Focus on race conditions, lock ordering, shared-resource contention, async error handling, and missing cancellation/timeout handling. Return numbered findings keyed to file paths and line numbers."

2. **Launch han-core:behavioral-analyst** — when the symptom involves data transformed wrong, values lost between modules, errors swallowed, state mutated unexpectedly, or integration boundaries passing bad data. Prompt: "Trace the data flow for the code paths implicated by this symptom: {symptom}. Focus on data transformation across module boundaries, error propagation and loss, state mutation, and integration-boundary assumptions. Return numbered findings keyed to file paths and line numbers."

3. **Launch han-core:data-engineer** — when the symptom involves wrong data in the database, slow queries, N+1, lock contention, migration failures, unbounded scans, lost data, broken referential integrity, or isolation-level surprises. Prompt: "Investigate the schema, queries, migrations, and data-access code implicated by this symptom: {symptom}. Focus on the specific data-engineering principles violated and the concrete data-level impact. Return numb