---
name: diagnostic-triage-questions
source: https://app.decimal.ai/s/diagnostic-triage-questions@1/SKILL.md
source_sha256: 2af345afd4e8
---

# Ask the diagnostic questions before proposing a fix

Someone hands you a problem — "checkout is broken," "the nightly job started failing," "users can't
log in" — and asks how to fix it. Left to itself, the model tends to jump straight to a plausible-
sounding fix: it guesses a cause and lists remedies before it knows the exact symptom, whether the
problem reproduces, or what changed. A fix aimed at an unconfirmed cause is a guess. Most of the
guesses are wrong, and each wrong one costs a round trip.

The discipline: when a problem is reported and the cause is not yet established, **spend your first
response gathering the small set of facts that most narrows the cause** — then propose a fix. Ask one
tight round of questions, not a slow one-at-a-time drip.

## The five high-information questions

Ask the ones the report has not already answered. These are ordered by how much they typically
narrow the cause:

1. **Exact symptom.** What is the *literal* error text, status code, or precise observed behavior —
   not "it's broken" but the actual message, and where it appears (log line, UI, API response).
2. **Reproduction.** Does it happen every time or intermittently? What are the smallest steps,
   inputs, or account that trigger it? A bug you can reproduce on demand is half solved.
3. **Timeline.** When did it start? What was the last known-good moment? Did it ever work, or is
   this a first-time setup?
4. **Scope / blast radius.** Who and what is affected — one user or everyone, one environment or all,
   one record or the whole table, one region or global? Scope separates "config typo" from "outage."
5. **What changed.** What happened right before it started — a deploy, a config or flag flip, a
   dependency bump, a data migration, an infra or upstream-provider change? Most regressions trace to
   the most recent change.

## How to ask

- **Batch them.** Put the 3–6 relevant questions in one message. Do not ask one, wait, ask the next.
- **Lead with the questions.** Don't bury them under a wall of speculative causes. It is fine to name
  your leading hypothesis in a line, but the ask comes first, not a pre-committed diagnosis.
- **Skip what's answered.** If the report already gives the exact error and a repro, don't re-ask —
  move to the questions that are still open (timeline, scope, what changed).
- **Prioritize by information value.** Ask the questions that split the space of causes in half.
  Avoid low-value questions ("have you tried restarting?", "are you sure it's actually broken?").

## When to skip the round and just fix it

Triage is a means, not a ritual. Proceed directly to a fix when the report **already** pins the
cause — e.g. it includes the exact stack trace, a reliable repro, and the offending line is
unambiguous — or the user explicitly says the cause is confirmed. In that case, state the one
assumption you're acting on ("assuming this reproduces on every request as described") and fix it. The
goal is to avoid *guessing*, not to interrogate a problem that is already understood.

## Example

> **Report:** "Our image uploads are failing. Can you fix it?"
>
> **Jump-to-fix (avoid):** "Sounds like a file-size limit. Raise `client_max_body_size` in nginx,
> bump the S3 multipart threshold, and increase the request timeout — that usually does it."
>
> **Triage first (aim for):** "Before I suggest a fix, five quick things so I don't guess wrong:
> (1) What exact error do users or the logs show when an upload fails? (2) Does it fail on every
> upload or only some — any pattern by file size or type? (3) When did this start? (4) Is it all
> users or a subset / one environment? (5) Any deploy, config, or dependency change around when it
> began? My leading guess is a size limit, but the answers will tell us."

Same leading hypothesis in both — but the second one confirms before it commits, and the answers
routinely rule the guess out.