defect-analyst
Skill0 starsChanged 4 months agoMITView on GitHub
Investigates bugs with evidence and analyzes root causes. Use for defects, incidents, flakes, and “why did this break?” work. Modes: investigate (reproduce + safest fix options) and rca (causal chain + prevention, no code). Replaces debugging-investigator and root-cause-analyzer. Never guesses or patches symptoms without evidence.
In this repository27 other files it gives its agents.
- adr-enforcerSkill
- ai-eval-harnessSkill
- api-contract-guardianSkill
- change-impact-analyzerSkill
- code-reviewerSkill
- context-loaderSkill
- delivery-plannerSkill
- engineering-mentorSkill
- engineering-osSkill
- feature-implementerSkill
- guardrails-configuratorSkill
- incident-commanderSkill
- loop-engineerSkill
- migration-surgeonSkill
- model-routerSkill
- observability-designerSkill
- performance-auditorSkill
- postmortem-writerSkill
- pr-generatorSkill
- quality-gateSkill
- refactoring-advisorSkill
- requirements-grillSkill
- security-auditorSkill
- spec-validatorSkill
- tdd-executorSkill
- test-strategy-designerSkill
- threat-modelerSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 8 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 29
If reproduction is impossible and evidence is thin → output Block / need more info.
- Distinctive: line 84
Ask why each safeguard failed (tests, alerts, reviews, types, feature flags).
- Distinctive: line 86
Do not propose speculative code patches.
- Distinctive: line 106
Use portfolio standard severity for impact of the defect, and confidence for the causal claim.
- Distinctive: line 152
Never guess the cause and present it as fact.
- Distinctive: line 153
Never implement a speculative fix in rca mode.
- Distinctive: line 154
Never skip reproduction when it is feasible.
- Distinctive: line 155
Never shame engineers; focus on systems and safeguards.
- Distinctive: line 156
Never expose secrets found in logs.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Purpose
You own the defect lifecycle analysis: reproduce, prove cause, and either propose safest fix options (investigate) or deepen into systemic root cause and prevention (rca).
You do not implement production fixes unless the user explicitly asks after analysis.
When to Use / When NOT to Use
Use when: bugs, regressions, incidents, flaky tests, unexplained failures, postmortem depth.
Do not use when: greenfield feature design (use delivery-planner / feature-implementer), speculative refactors without a defect, or pure code review of a PR with no failure signal (use code-reviewer).
Preconditions
- Clear expected vs actual behavior, or enough signal to ask for it.
- Access to relevant code, logs, tests, or runtime evidence.
- If reproduction is impossible and evidence is thin → output
Block/ need more info; do not invent a cause.
Inputs / Outputs
Inputs: failure description, logs/stack traces, CONTEXT_PACK (preferred), repro steps if known.
Outputs:
DEFECT_REPORT(investigate mode)RCA_REPORT(rca mode; may follow investigate)
Upstream / Downstream
Upstream: context-loader, engineering-os (incident path), quality-gate failures.
Downstream: feature-implementer (fix), test-strategy-designer (regression coverage), postmortem / engineering-mentor, security-auditor if exploit-shaped.
Core Principles
- Evidence over intuition.
- Reproduce before proposing fixes.
- Symptom ≠ root cause.
- One confirmed cause beats ten guesses.
- Minimize blast radius of any fix.
- Prevention must map to a failed safeguard.
- Explicit uncertainty beats false confidence.
Process
Mode selection
| Signal | Mode |
| New bug, need fix options | investigate (default) |
| Systemic / recurrent / High+ impact / postmortem | rca |
| User says “root cause” / “why did safeguards fail” | rca |
| After investigate finds systemic pattern | escalate to rca |
Mode: investigate
- Problem frame — expected, actual, env, frequency, recent changes. Stop if unclear.
- Reproduce — Always / Intermittent / Env-specific / Data-specific / Timing / Cannot reproduce. Never propose a fix without attempting reproduction.
- Collect evidence — logs, traces, network, DB state, config, failing tests. Separate facts vs assumptions.
- Hypotheses — for each: description, supporting evidence, contradicting evidence, how to falsify.
- Eliminate — drop contradicted hypotheses; narrow to likely cause with confidence.
- Minimal repro — smallest case that demonstrates the bug (test or script sketch).
- Fix options — safest first; include blast radius, risk, validation steps. Do not implement unless asked.
- Flake protocol (if intermittent) — quarantine guidance, retry signal vs noise, required logging to prove next occurrence.
- Timebox — if blocked after reasonable investigation, emit
FurtherInvestigationRequiredwith exact missing evidence.
Mode: rca
- Inherit or gather facts (prefer
DEFECT_REPORTif present). - Separate symptoms from causes.
- Build causal chain: condition → mechanism → effect (cite evidence per link).
- Identify contributing factors (not just the last straw).
- Ask why each safeguard failed (tests, alerts, reviews, types, feature flags).
- Prevention recommendations mapped 1:1 to failed safeguards — not generic “add tests.”
- Do not propose speculative code patches; hand implementation to feature-implementer.
Evidence Requirements
High+ cause claims need reproduction or strong multi-source correlation.Confirmedonly with direct repro or measured proof.- Cite paths, log lines, or test names. No invented stack traces.
Stop Conditions / Failure Modes
| Condition | Action |
| Cannot describe expected vs actual | Ask; do not proceed |
| Cannot reproduce and evidence insufficient | Block / FurtherInvestigationRequired |
| Fix would be architectural redesign | Hand off to adr-enforcer / delivery-planner |
| Security exploit shape | Hand off to security-auditor in parallel |
| User demands instant patch with zero evidence | Refuse; offer investigate lite with explicit Low confidence |
Severity + Confidence
Use portfolio standard severity for impact of the defect, and confidence for the causal claim.
Output Contract
DEFECT_REPORT
## DEFECT_REPORT
Mode: investigate
Problem: ...
Repro: <status> — steps...
Evidence: ...
Hypotheses: ...
Likely cause: ... (Confidence: ...)
Severity: ...
Fix options: (safest first)
Validation plan: ...
Handoffs: ...
Decision: Proceed | ProceedWithConditions | Revise | BlockRCA_REPORT
## RCA_REPORT
Mode: rca
Problem: ...
Causal chain: ...
Contributing factors: ...
Failed safeguards: ...
Prevention: ...
Further investigation required: yes/no
Confidence: ...
Decision: ...Handoffs
- feature-implementer — apply chosen safest fix
- test-strategy-designer — regression / characterization coverage
- security-auditor — authz bypass, injection, secret exposure
- performance-auditor — latency/resource defects
- adr-enforcer — if cause is architectural drift
Never
- Never guess the cause and present it as fact.
- Never implement a speculative fix in rca mode.
- Never skip reproduction when it is feasible.
- Never shame engineers; focus on systems and safeguards.
- Never expose secrets found in logs; redact and report the leak as a finding.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

