debugging-and-error-recovery

Diagnose test, build, and runtime failures through a six-step triage workflow.

4|Updated Jun 19, 2026
One-click install
npx skills add https://github.com/douglance/sdlc-plugin --skill debugging-and-error-recovery-douglance
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: debugging-and-error-recovery
Source: https://github.com/douglance/sdlc-plugin/tree/main/.rulesync/skills/debugging-and-error-recovery
Command: npx skills add https://github.com/douglance/sdlc-plugin --skill debugging-and-error-recovery-douglance

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a test fails, a build breaks, or runtime behavior diverges from expectations, developers often patch symptoms instead of root causes or push past failures and compound errors. This Skill enforces a disciplined stop-the-line workflow that preserves evidence, localizes the failure, fixes the root cause, and guards against recurrence. ## Core Features & Use Cases - Six-Step Triage Checklist: Reproduce, localize, reduce, fix the root cause, add a regression test, and verify end-to-end, with decision trees for each step. - Error-Specific Triage Patterns: Dedicated decision trees for test failures, build failures, and runtime errors, plus git bisect guidance for regression hunting. - Safe Fallbacks and Instrumentation: Patterns for graceful degradation, safe config defaults, and rules for when to add or remove diagnostic logging. - Use Case: A test suite fails after a refactor. Follow the checklist to reproduce the failure in isolation, bisect to the offending commit, reduce to a minimal case, fix the underlying cause, and add a regression test that fails without the fix. ## Quick Start Use the debugging-and-error-recovery skill to triage this failing test and identify the root cause before fixing it.

Frequently Asked Questions about debugging-and-error-recovery

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug a failing test after a code change?▼

Run the failing test in isolation with verbose output, then check whether the test or the code is wrong. If unrelated code changed, look for side effects through shared state, imports, or globals before modifying anything.

How to find which commit introduced a bug with git bisect?▼

Run git bisect start, mark the current commit bad and a known-working commit good, then test each midpoint checkout. You can automate it with git bisect run followed by your test command to identify the exact breaking commit.

What should I do when a bug is not reproducible?▼

Classify the failure as timing-dependent, environment-dependent, state-dependent, or truly random. Add timestamps or artificial delays for race conditions, compare environments, check for leaked shared state, or add defensive logging with alerts for the error signature.

Why is fixing symptoms instead of root causes a problem?▼

Symptom fixes mask the underlying defect, which resurfaces elsewhere and compounds with later changes. Ask why the failure happens repeatedly until you reach the actual cause, then verify with a regression test that fails without the fix.

When should I remove debug logging from my code?▼

Remove instrumentation once the bug is fixed and a regression test guards against recurrence, or when logs are only useful during development. Always remove logs containing sensitive data, but keep permanent error boundaries and API error logging.