| name | analysis-workflow |
| description | Analyze, validate, debug, troubleshoot, critique, red-team, adversarial, or what-could-go-wrong questions. Not for PR/diff review; use code-review. |
Analysis Workflow
Boundary
| Need | Use |
|---|
| Debugging, validation, root-cause analysis, red-team critique | analysis-workflow |
| Reviewing a diff/branch/PR/commit for findings | code-review |
| Logs, metrics, traces, alerts, SLOs | logging-observability |
| Failed live mutation | Follow the active repository incident policy |
Core Principle
Structured evidence beats analysis theater. Form hypotheses, test them, and separate observed facts from guesses.
Practical Steps
- State the question or failure mode.
- Gather direct evidence before proposing fixes.
- List plausible hypotheses and what would falsify each.
- Run the cheapest decisive check first.
- Distinguish confirmed facts, likely causes, and unknowns.
- Recommend the smallest next action backed by evidence.
Debugging Checklist
- What changed recently?
- Can the issue be reproduced?
- What exact input/state triggers it?
- Which layer first diverges from expected behavior?
- What evidence would disprove the leading theory?
Anti-Patterns
- Producing long critique without checking evidence.
- Treating correlation as cause.
- Jumping to broad refactors before isolating the fault.
- Reporting risks without probability, impact, or mitigation.
- Retrying without evidence that distinguishes a new hypothesis.