Systematic Diagnosis
Determine the most strongly supported cause before changing the system.
Workflow
- Capture the observed symptom, expected behavior, environment, and smallest known reproduction.
- Reproduce safely when possible. Preserve the exact command, input, output, and revision.
- Map the path from input to failure and identify the first boundary where observed state diverges from expected state.
- Form a small set of competing hypotheses with discriminating tests.
- Run the cheapest read-only or reversible test that can eliminate a hypothesis.
- Check whether the failure is isolated, environment-specific, order-dependent, intermittent, or shared by related paths.
- Stop when one cause is supported well enough to explain the evidence, or report the remaining uncertainty explicitly.
Boundaries
- Diagnosis does not authorize implementation. Do not edit files, restart shared services, change remote state, or deploy unless the user also requested a fix.
- Do not label correlation, a passing standalone test, or the last changed file as the cause without a causal check.
- Treat sandbox, permission, network, and provider failures as environment evidence until product behavior is independently implicated.
Output
Report Symptom, Reproduction, Cause, Evidence, Alternatives eliminated, Impact, and Fix direction. If no cause is established, say Diagnosis incomplete and name the next discriminating observation.
1---2name: systematic-diagnosis3description: Diagnose a defect, failure, regression, or confusing behavior by reproducing it, narrowing the causal boundary, and reporting evidence. Use when the user asks why something fails or requests diagnosis without necessarily authorizing a fix.4license: MIT5---67# Systematic Diagnosis89Determine the most strongly supported cause before changing the system.1011## Workflow12131. Capture the observed symptom, expected behavior, environment, and smallest known reproduction.142. Reproduce safely when possible. Preserve the exact command, input, output, and revision.153. Map the path from input to failure and identify the first boundary where observed state diverges from expected state.164. Form a small set of competing hypotheses with discriminating tests.175. Run the cheapest read-only or reversible test that can eliminate a hypothesis.186. Check whether the failure is isolated, environment-specific, order-dependent, intermittent, or shared by related paths.197. Stop when one cause is supported well enough to explain the evidence, or report the remaining uncertainty explicitly.2021## Boundaries2223- Diagnosis does not authorize implementation. Do not edit files, restart shared services, change remote state, or deploy unless the user also requested a fix.24- Do not label correlation, a passing standalone test, or the last changed file as the cause without a causal check.25- Treat sandbox, permission, network, and provider failures as environment evidence until product behavior is independently implicated.2627## Output2829Report `Symptom`, `Reproduction`, `Cause`, `Evidence`, `Alternatives eliminated`, `Impact`, and `Fix direction`. If no cause is established, say `Diagnosis incomplete` and name the next discriminating observation.