systematic-debugging

Trace root causes of test failures and bugs before implementing fixes.

11|1|Updated Apr 10, 2026
One-click install
npx skills add https://github.com/Arcanada-one/datarim --skill systematic-debugging-arcanada-one
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging
Source: https://github.com/Arcanada-one/datarim/tree/main/skills/systematic-debugging
Command: npx skills add https://github.com/Arcanada-one/datarim --skill systematic-debugging-arcanada-one

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill prevents wasteful guess-and-check debugging by enforcing root-cause investigation before any implementation changes, so fixes are reliable and bugs do not reappear.

Core Features & Use Cases

  • Four-phase debugging workflow: Root cause investigation, pattern analysis, hypothesis testing, then single-fix implementation.
  • Evidence-first approach: Reproduce consistently, review recent changes, and collect data across component boundaries.
  • Data-flow and call-stack tracing: Trace inputs backward to the original trigger instead of fixing symptoms.
  • Fail-fast safety rails: Stop when red flags appear, especially after repeated failed fixes (>= 3) to avoid architectural thrashing.

Use for test failures, bugs in production, unexpected behavior, performance problems, build failures, and integration issues—especially under time pressure or when prior fixes have failed.

Quick Start

Use systematic-debugging when you hit a test failure or unexpected behavior and you need the root cause before making any changes.

Frequently Asked Questions about systematic-debugging

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

FAQPage Schema
How do I find the root cause of a test failure before attempting a fix?

To find the root cause of a test failure, you must complete a systematic investigation phase that reproduces the issue consistently, reviews recent changes, and traces data flow backward to the original trigger before proposing any fixes.

What is the best way to debug CI pipeline build failures across multiple components?

The best way to debug CI pipeline build failures across multiple components is to trace inputs backward through component boundaries and analyze call-stack failures, ensuring you verify a single hypothesis with minimal changes before implementing a fix.

Why do my bug fixes keep failing in production, and how can I stop recurring issues?

Bug fixes keep failing in production when symptoms are patched instead of root causes; stop recurring issues by enforcing evidence-first pattern analysis and hypothesis testing before applying exactly one verified fix.

When should I stop trying to fix a bug to avoid architectural thrashing?

You should stop attempting fixes to avoid architectural thrashing when fail-fast safety rails trigger, specifically after repeated failed fixes reach three attempts, indicating a need to restart root-cause investigation.

Can I use systematic debugging for unexpected performance problems and integration issues?

Yes, you can use systematic debugging for unexpected performance problems and integration issues by applying the four-phase workflow: root cause investigation, pattern analysis, hypothesis testing, and single-fix implementation with explicit failing-test evidence.