/think-diagnose

name: think-diagnose
description: Abductive reasoning about causes. Takes a phenomenon, separates observations from interpretations, then spawns diagnosticians applying different reasoning lenses (technical, human-factors, process, incentive-structure, environmental, temporal, measurement-artifact, statistical) in isolation. Orchestrator evaluates candidate causes for fit-against-evidence, calibrates confidence honestly, and reports leading candidate(s) with distinguishing evidence needed. Produces feedback only — no code, no tickets, no artifacts.
model: opus

Think-Diagnose - Abductive Reasoning About Causes

Takes a phenomenon — something that was observed and that the user wants to understand — and produces a ranked set of candidate causes with evidence-based confidence calibration. Uses **abductive reasoning**: inference to the best explanation. Distinct from `/bug-fix` (which handles code-specific diagnosis with artifact output and execution tooling); `/think-diagnose` is pure reasoning about causes, applicable to non-code phenomena as readily as code ones.

**This skill produces no tangible artifacts.** It is a consultant, not an implementer. No code, no tickets, no commits. The output is a structured diagnosis report that the user can act on by gathering more evidence, adopting a leading cause, or piping to `/think-brainstorm` for remediation.

Roles

**Judge (you, running this skill):**

• Capture the phenomenon in a written brief
• Elicit evidence, rigorously separating observation from interpretation
• Choose appropriate reasoning lenses
• Spawn diagnosticians in isolation
• **Evaluate** candidate causes against evidence (this skill has a real evaluative phase, unlike purely-divergent think-* skills)
• Calibrate confidence honestly and report

**Diagnosticians:** Each receives a specific reasoning lens and generates candidate causes (with mechanisms, predictions, refuters, and plausibility) in isolation from other diagnosticians.

Workflow

1. Receive the Phenomenon

The phenomenon may arrive as:

• **Conversation context** — summarize it back, confirm
• **A document** — read the file (incident report, data summary, observation log)
• **Fresh user input** — capture verbatim

**Produce a written brief** of the phenomenon. Precisely what is the thing to explain? Vague phenomena produce vague diagnoses.

2. Gather Evidence — Separate Observation from Interpretation

**This is the most failure-prone step in the entire workflow, and it has enforced structure.** Most bad diagnoses start by accepting interpretations as observations.

**Elicit from the user, in three distinct buckets:**

• **Observations** — concrete things that were measured, seen, or experienced. "The metric dropped 30% on March 14th." "Three customers mentioned X in surveys." "The build broke at commit abc123."
• **Interpretations already held** — what the user or others have already *inferred* from the observations. "The team thinks it's because of the migration." "We believe the drop is due to seasonality." Flag these explicitly so diagnosticians know not to accept them as given.
• **Unavailable / unknown evidence** — what's unknown, wasn't measured, or can't be retrieved. "We don't have per-user data before April." "We didn't log the old config."

**Push back on smuggled interpretations.** If the user says "the metric dropped because of the migration," that's two claims: (a) the metric dropped (observation) and (b) the migration caused it (interpretation). Separate them before proceeding.

**3-6 clarifying questions is typical** to establish this split. Stop when you have enough to pass diagnosticians material they can work with.

3. Choose Reasoning Lenses

Select 3-6 lenses from the palette based on the phenomenon's shape.

**Available lenses:**

• **technical** — engineering-level causes (code, infra, config, capacity, dependencies)
• **human-factors** — people, skills, fatigue, turnover, miscommunication, team dynamics
• **process** — broken or missing process, handoffs, approvals, ownership, rituals
• **incentive-structure** — the system rewards the behavior we're diagnosing (Goodhart territory)
• **environmental** — external factors (market, regulation, customer mix, vendor, upstream)
• **temporal** — something changed in time that correlates with the phenomenon
• **measurement-artifact** — the phenomenon isn't real, it's a metric/instrumentation issue
• **statistical** — base rates, regression to mean, Simpson's paradox, confounders, selection

**Selection heuristics:**

• Phenomenon is metric-based? **Always include measurement-artifact.** Underrated; catches a large share of false phenomena.
• Phenomenon has a clear onset date? Include temporal.
• Phenomenon involves aggregate data (averages, ratios)? Include statistical.
• Phenomenon is in a team/org context? Include human-factors, process, incentive-structure.
• Phenomenon is in a codebase or system? Include technical.
• Phenomenon occurs in a context with external inputs (customers, markets, vendors)? Include environmental.

**Drop lenses that don't fit.** A phenomenon in a closed system without external dependencies probably doesn't need environmental. A phenomenon observed directly (not through metrics) probably doesn't need measurement-artifact.

4. Spawn Diagnosticians (Parallel, Isolated)

Spawn one `THK - Diagnostician` agent per chosen lens, in parallel. Each receives:

• The phenomenon brief
• The observations
• The interpretations already held (flagged — not to be accepted as given)
• The unavailable evidence
• Its assigned lens
• Instruction to generate 3-8 candidate causes, each with mechanism / predictions / refuters / plausibility

**No cross-talk between diagnosticians.** NGT principle — independent reasoning first, evaluation second. Isolated diagnosticians produce more distinct candidate causes; coordinated ones anchor on the first compelling story.

Collect all candidate causes.

5. Evaluate Fit — Orche