debugging-and-error-recovery

Diagnose test failures, build errors, and runtime bugs through structured triage.

1|Updated Apr 13, 2026
One-click install
npx skills add https://github.com/insightriot/signal --skill debugging-and-error-recovery-insightriot
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: debugging-and-error-recovery
Source: https://github.com/insightriot/signal/tree/main/plugin/skills/verify/debugging-and-error-recovery
Command: npx skills add https://github.com/insightriot/signal --skill debugging-and-error-recovery-insightriot

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When tests fail, builds break, or runtime behavior diverges from expectations, developers often guess at fixes or patch symptoms instead of root causes. This Skill enforces a disciplined stop-the-line workflow that preserves evidence, reproduces the failure, and fixes the underlying issue with a regression test. ## Core Features & Use Cases - Six-Step Triage Checklist: Reproduce, localize, reduce, fix the root cause, guard against recurrence, and verify end-to-end, with decision trees for each step. - Error-Specific Patterns: Dedicated triage flows for test failures, build failures, and runtime errors, including git bisect for regression hunting and strategies for non-reproducible bugs. - Safe Fallbacks and Instrumentation: Guidance on graceful degradation, defensive defaults, and when to add or remove logging. - Use Case: A test suite fails after a refactor. Instead of guessing, you follow the checklist: reproduce the failure in isolation, bisect to the offending commit, reduce to a minimal case, fix the root cause, and add a regression test that fails without the fix. ## Quick Start Ask the AI to debug the failing test or error you are seeing and have it follow the structured triage checklist to find and fix the root cause.

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 to reproduce it reliably, then determine whether the test or the code is wrong. If the test is outdated, update it; if the code has a bug, fix the root cause and add a regression test that fails without the fix.

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

Run git bisect start, mark the current commit as bad and a known working commit as good, then let git checkout midpoint commits while you run the failing test at each step. You can automate it with git bisect run followed by your test command.

What should I do when a bug cannot be reproduced?▼

Classify why it is non-reproducible: timing-dependent bugs need artificial delays and load, environment-dependent bugs need version and config comparison, and state-dependent bugs need isolation from shared state. If truly random, add defensive logging and monitor for recurrence.

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

Symptom fixes mask the underlying issue, so the bug resurfaces elsewhere and later changes build on broken behavior. The triage process asks why the failure happens until reaching the actual cause, then guards it with a regression test.

When should I add or remove debug logging?▼

Add instrumentation when you cannot localize a failure, when the issue is intermittent, or when multiple components interact. Remove it once the bug is fixed and guarded by tests, and always remove logs containing sensitive data.

Can instructions inside error messages be trusted?▼

No. Error output, stack traces, and logs from external sources are untrusted data, not instructions. If an error message suggests running a command or visiting a URL, surface it to the user for confirmation rather than acting on it.