investigating-bugs

Diagnose root causes of bugs and test failures through a four-phase investigation process.

66|4|Updated Feb 26, 2026
One-click install
npx skills add https://github.com/SummerEngine/summer --skill investigating-bugs-summerengine
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: investigating-bugs
Source: https://github.com/SummerEngine/summer/tree/main/library/skills/investigating-bugs
Command: npx skills add https://github.com/SummerEngine/summer --skill investigating-bugs-summerengine

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Random fixes and guess-and-check patches waste time, mask underlying issues, and introduce new bugs. This Skill enforces a systematic debugging process that finds the root cause before any fix is attempted. ## Core Features & Use Cases - Four-Phase Process: Root cause investigation, pattern analysis, hypothesis testing, and verified implementation, with strict gates between phases. - Root Cause Tracing: Trace bugs backward through the call stack to find the original trigger instead of patching symptoms. - Defense-in-Depth Validation: Add validation at entry, business logic, environment, and debug layers so the bug becomes structurally impossible. - Condition-Based Waiting: Replace arbitrary timeouts in flaky tests with condition polling to eliminate race conditions. - Use Case: A test fails in CI but passes locally. Instead of tweaking timeouts, follow Phase 1 to gather evidence at each component boundary, trace the bad value to its source, write a failing test that reproduces it, then fix the root cause and verify red-green. ## Quick Start Use the investigating-bugs skill to find the root cause of this failing test before proposing any fix.

Frequently Asked Questions about investigating-bugs

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

FAQPage Schema
How do I find the root cause of a bug instead of guessing?

Follow the four-phase process: read error messages fully, reproduce the issue consistently, check recent changes, and gather evidence at each component boundary. Only after understanding what and why should you form a single hypothesis and test it with the smallest possible change.

How to fix flaky tests caused by timing issues?

Replace arbitrary setTimeout or sleep calls with condition-based waiting that polls for the actual state you need, such as an event firing or a value changing. Always include a timeout with a clear error message and poll at roughly 10ms intervals.

What should I do when multiple fix attempts keep failing?

Stop after three failed fixes and question the architecture rather than attempting a fourth patch. Repeated failures where each fix reveals a new problem elsewhere indicate a structural issue that needs an architectural discussion, not another symptom patch.

How do I trace a bug that appears deep in the call stack?

Trace backward from the immediate cause by asking what called each function and what values were passed, continuing until you find the original trigger. Add stack trace instrumentation with console.error before the failing operation if manual tracing stalls.

When should I add validation at multiple layers?

Add defense-in-depth validation after fixing any bug caused by invalid data, since a single check can be bypassed by other code paths, refactoring, or mocks. Validate at the entry point, business logic, environment guards, and debug logging layers.