debugging-and-error-recovery

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

5|Updated Mar 5, 2024
One-click install
npx skills add https://github.com/TRAPZZY/God-Eyes --skill debugging-and-error-recovery-trapzzy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: debugging-and-error-recovery
Source: https://github.com/TRAPZZY/God-Eyes/tree/main/.skills/debugging-and-error-recovery
Command: npx skills add https://github.com/TRAPZZY/God-Eyes --skill debugging-and-error-recovery-trapzzy

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 root causes, wasting hours and letting bugs compound. This Skill enforces a disciplined stop-the-line workflow that preserves evidence, localizes the failure, and fixes the actual cause. ## Core Features & Use Cases - Structured Triage Checklist: A six-step process covering reproduce, localize, reduce, fix root cause, guard against recurrence, and verify end-to-end. - Error-Specific Decision Trees: Dedicated triage flows for test failures, build failures, runtime errors, and non-reproducible bugs including timing, environment, and state-dependent issues. - Regression Guarding: Guidance on writing tests that fail without the fix, plus safe fallback patterns and instrumentation rules. - Use Case: A CI build breaks after a merge. Instead of guessing, you follow the checklist: reproduce locally, bisect with git to find the offending commit, reduce to a minimal failing 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 failing case, and fix the root cause rather than the symptom. Finish by adding a regression test that fails without the fix and running the full suite to check for regressions.

How to find which commit introduced a bug?▼

Use git bisect to binary-search the commit history. Mark the current commit as bad and a known working commit as good, then run your failing test at each midpoint checkout, optionally automated with git bisect run.

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

Classify whether it is timing-dependent, environment-dependent, state-dependent, or truly random. Add timestamps and defensive logging, try artificial delays to widen race windows, compare environments, and run the scenario in isolation to expose leaked state.

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 reaching the actual cause produces durable fixes and prevents recurring incidents.

When should I remove debug logging after fixing a bug?▼

Remove temporary instrumentation once the bug is fixed and a regression test guards against recurrence, especially if logs contain sensitive data. Keep permanent instrumentation like error boundaries, API error logging with request context, and performance metrics.