Investigate Root Cause
Find the cause before changing code.
Rules
- Do not start with a fix.
- Reproduce or verify the symptom when practical.
- Separate observation, inference, and hypothesis.
- Prefer commands and code references over guesses.
- Stop and ask before using production systems, secrets, destructive commands, or external services.
Clarifying Questions
- Ask before investigation if the failing command, expected behavior, environment, reproduction steps, affected version, or recent change is missing and cannot be discovered locally.
- Do not proceed on assumptions that affect the symptom, cause, safety, data, environment, or verification.
- Ask numbered questions with lettered options; option A must be recommended. Continue once the failure can be investigated without decision-critical assumptions.
Do Not Trigger
- Root cause is already proven and the user asks for a small direct fix.
- Design tradeoffs.
- Expectation mismatch without failure evidence.
Workflow
- Define the symptom: what failed, what was expected, what changed, what environment is involved.
- Gather evidence: run the failing command when practical, read logs/stack traces, search error text and related code/config.
- Build a cause chain: immediate failure, local code/config/input cause, missing guardrail, recurrence-prevention change.
- Validate hypotheses with the smallest command or inspection that can disprove them.
- If not reproduced, report commands tried, observed result, missing evidence, and safest next step.
- Recommend or implement the smallest safe fix only after the cause is validated.
Output
**Symptom**
[Observed failure.]
**Evidence**
- [Command/log/code reference.]
**Root Cause**
[Validated cause, or "not reproduced".]
**Fix**
[Smallest safe change or next diagnostic step.]
**Verification**
[Command/result.]
For incident/postmortem-lite output, include impact, timeline, detection, resolution, root/contributing causes, and follow-up actions.
Anti-Patterns
- Do not patch error handling without understanding why the error occurred.
- Do not assume flaky behavior is infrastructure until local causes are checked.
- Do not broaden scope into refactoring unless required for the fix.
1---2name: investigate-root-cause3description: Systematic debugging and root cause analysis for concrete failures: errors, failing tests, build failures, logs, stack traces, flaky behavior, performance regressions, integration failures, and reproducible wrong behavior. Use before applying fixes when the cause is uncertain; use clarify-confusion for expectation mismatches without failure evidence.4---56# Investigate Root Cause78Find the cause before changing code.910## Rules1112- Do not start with a fix.13- Reproduce or verify the symptom when practical.14- Separate observation, inference, and hypothesis.15- Prefer commands and code references over guesses.16- Stop and ask before using production systems, secrets, destructive commands, or external services.1718## Clarifying Questions1920- Ask before investigation if the failing command, expected behavior, environment, reproduction steps, affected version, or recent change is missing and cannot be discovered locally.21- Do not proceed on assumptions that affect the symptom, cause, safety, data, environment, or verification.22- Ask numbered questions with lettered options; option A must be recommended. Continue once the failure can be investigated without decision-critical assumptions.2324## Do Not Trigger2526- Root cause is already proven and the user asks for a small direct fix.27- Design tradeoffs.28- Expectation mismatch without failure evidence.2930## Workflow31321. Define the symptom: what failed, what was expected, what changed, what environment is involved.332. Gather evidence: run the failing command when practical, read logs/stack traces, search error text and related code/config.343. Build a cause chain: immediate failure, local code/config/input cause, missing guardrail, recurrence-prevention change.354. Validate hypotheses with the smallest command or inspection that can disprove them.365. If not reproduced, report commands tried, observed result, missing evidence, and safest next step.376. Recommend or implement the smallest safe fix only after the cause is validated.3839## Output4041```markdown42**Symptom**43[Observed failure.]4445**Evidence**46- [Command/log/code reference.]4748**Root Cause**49[Validated cause, or "not reproduced".]5051**Fix**52[Smallest safe change or next diagnostic step.]5354**Verification**55[Command/result.]56```5758For incident/postmortem-lite output, include impact, timeline, detection, resolution, root/contributing causes, and follow-up actions.5960## Anti-Patterns6162- Do not patch error handling without understanding why the error occurred.63- Do not assume flaky behavior is infrastructure until local causes are checked.64- Do not broaden scope into refactoring unless required for the fix.
gslava