agentleFS
willianbswillianbs/skills/defect-analyst/SKILL.md

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.

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
  1. Very specific:

    If reproduction is impossible and evidence is thin → output Block / need more info.

    line 29
  2. Distinctive:

    Ask why each safeguard failed (tests, alerts, reviews, types, feature flags).

    line 84
  3. Distinctive:

    Do not propose speculative code patches.

    line 86
  4. Distinctive:

    Use portfolio standard severity for impact of the defect, and confidence for the causal claim.

    line 106
  5. Distinctive:

    Never guess the cause and present it as fact.

    line 152
  6. Distinctive:

    Never implement a speculative fix in rca mode.

    line 153
  7. Distinctive:

    Never skip reproduction when it is feasible.

    line 154
  8. Distinctive:

    Never shame engineers; focus on systems and safeguards.

    line 155
  9. Distinctive:

    Never expose secrets found in logs.

    line 156

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. Evidence over intuition.
  2. Reproduce before proposing fixes.
  3. Symptom ≠ root cause.
  4. One confirmed cause beats ten guesses.
  5. Minimize blast radius of any fix.
  6. Prevention must map to a failed safeguard.
  7. Explicit uncertainty beats false confidence.

Process

Mode selection

SignalMode
New bug, need fix optionsinvestigate (default)
Systemic / recurrent / High+ impact / postmortemrca
User says “root cause” / “why did safeguards fail”rca
After investigate finds systemic patternescalate to rca

Mode: investigate

  1. Problem frame — expected, actual, env, frequency, recent changes. Stop if unclear.
  2. Reproduce — Always / Intermittent / Env-specific / Data-specific / Timing / Cannot reproduce. Never propose a fix without attempting reproduction.
  3. Collect evidence — logs, traces, network, DB state, config, failing tests. Separate facts vs assumptions.
  4. Hypotheses — for each: description, supporting evidence, contradicting evidence, how to falsify.
  5. Eliminate — drop contradicted hypotheses; narrow to likely cause with confidence.
  6. Minimal repro — smallest case that demonstrates the bug (test or script sketch).
  7. Fix options — safest first; include blast radius, risk, validation steps. Do not implement unless asked.
  8. Flake protocol (if intermittent) — quarantine guidance, retry signal vs noise, required logging to prove next occurrence.
  9. Timebox — if blocked after reasonable investigation, emit FurtherInvestigationRequired with exact missing evidence.

Mode: rca

  1. Inherit or gather facts (prefer DEFECT_REPORT if present).
  2. Separate symptoms from causes.
  3. Build causal chain: condition → mechanism → effect (cite evidence per link).
  4. Identify contributing factors (not just the last straw).
  5. Ask why each safeguard failed (tests, alerts, reviews, types, feature flags).
  6. Prevention recommendations mapped 1:1 to failed safeguards — not generic “add tests.”
  7. Do not propose speculative code patches; hand implementation to feature-implementer.

Evidence Requirements

  • High+ cause claims need reproduction or strong multi-source correlation.
  • Confirmed only with direct repro or measured proof.
  • Cite paths, log lines, or test names. No invented stack traces.

Stop Conditions / Failure Modes

ConditionAction
Cannot describe expected vs actualAsk; do not proceed
Cannot reproduce and evidence insufficientBlock / FurtherInvestigationRequired
Fix would be architectural redesignHand off to adr-enforcer / delivery-planner
Security exploit shapeHand off to security-auditor in parallel
User demands instant patch with zero evidenceRefuse; 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 | Block

RCA_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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.