debugging-and-error-recovery

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

Updated Aug 15, 2026
One-click install
npx skills add https://github.com/jacksonlee-tw/mystock-vue --skill debugging-and-error-recovery-jacksonlee-tw
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: debugging-and-error-recovery
Source: https://github.com/jacksonlee-tw/mystock-vue/tree/main/mystock-vue/.agents/skills/debugging-and-error-recovery
Command: npx skills add https://github.com/jacksonlee-tw/mystock-vue --skill debugging-and-error-recovery-jacksonlee-tw

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When tests fail, builds break, or runtime behavior goes wrong, developers often guess at fixes or patch symptoms instead of causes. This Skill enforces a systematic six-step triage process that finds and fixes the actual root cause while preserving evidence and preventing recurrence. ## Core Features & Use Cases - Structured Triage Checklist: A six-step workflow covering reproduce, localize, reduce, fix root cause, guard with regression tests, and verify end-to-end. - Error-Specific Decision Trees: Dedicated triage paths for test failures, build failures, and runtime errors, including non-reproducible and flaky bug handling. - Safe Fallback Patterns: Guidance on graceful degradation, defensive defaults, and instrumentation that is added and removed deliberately. - Use Case: A previously passing test suite breaks after a refactor. Follow the checklist to reproduce the failure, bisect the offending commit with git bisect, reduce to a minimal case, fix the root cause, and add a regression test before resuming feature work. ## Quick Start Use the debugging-and-error-recovery skill to triage this failing test and find its 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 systematically?▼

Reproduce the failure reliably first, then localize which layer is failing, reduce to a minimal case, and fix the root cause rather than the symptom. Finish by adding a regression test that fails without the fix and verifying the full suite passes.

How to find which commit introduced a bug?▼

Use git bisect: 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 is not reproducible?▼

Classify it as timing-dependent, environment-dependent, state-dependent, or truly random, then apply the matching strategy: add timestamps and artificial delays, compare environments, check for leaked shared state, or add defensive logging and alerting until it recurs.

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

Symptom fixes mask the underlying defect, so the bug resurfaces elsewhere and compounds with later changes. Asking why the failure happens until you reach the actual cause produces a durable fix that a regression test can guard.

When should I add or remove debug logging?▼

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