crew-debugging

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

2|Updated Jul 28, 2026
One-click install
npx skills add https://github.com/mbadali25/useful-claude-add-ons --skill crew-debugging-mbadali25
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: crew-debugging
Source: https://github.com/mbadali25/useful-claude-add-ons/tree/main/plugin/crew/skills/crew-debugging
Command: npx skills add https://github.com/mbadali25/useful-claude-add-ons --skill crew-debugging-mbadali25

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? When facing a bug, test failure, or performance issue, the temptation is to guess at a quick fix — which often treats symptoms instead of causes and leads to repeated failed attempts. This Skill enforces a disciplined root-cause-first debugging method so fixes actually stick. ## Core Features & Use Cases - Four-phase systematic method: Root cause investigation, pattern analysis, single-hypothesis testing, then verified implementation — with an Iron Law of no fixes before investigation. - Repository evidence integration: Reads the repo's code map landmines, schema notes, code graph, and verification map so Phase 1 starts from recorded failure modes instead of an empty context. - Supporting techniques: Includes root-cause tracing through call stacks, defense-in-depth validation layers, condition-based waiting to replace flaky timeouts, and a bash script that bisects a test suite to find which test pollutes shared state. - Use Case: A payment test fails intermittently despite added sleep delays. Instead of increasing the timeout again, the Skill walks you through reproducing reliably, tracing the bad value to its source, forming one hypothesis, and verifying a minimal fix with the repo's mapped check commands. ## Quick Start Ask the AI to debug a failing test or bug using the systematic debugging skill before proposing any fix.

Frequently Asked Questions about crew-debugging

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

FAQPage Schema
How do I find the root cause of a bug before fixing it?

Follow a four-phase process: read error messages fully, reproduce the issue consistently, check recent changes, and gather evidence at component boundaries. Then form one specific hypothesis and test it with the smallest possible change before implementing any fix.

How to fix flaky tests caused by timing issues?

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

How do I find which test creates unwanted files or state?

Use the find-polluter.sh bisection script with the pollution marker path and a test file pattern. It runs each test individually, checks whether the marker appeared, and reports the polluting test or flags runner failures separately.

What should I do when three or more fixes have failed?

Stop attempting more fixes and question the architecture instead. Repeated failures where each fix reveals new problems elsewhere indicate a structural issue, so discuss refactoring the pattern with your team rather than attempting a fourth fix.

When is it acceptable to skip systematic debugging for simple bugs?

Never — simple bugs have root causes too, and the process is fast for simple cases. Skipping investigation under time pressure or for obvious-looking issues leads to symptom fixes that fail and require rework.