systematic-debugging-extras

Verifies stated root causes and prescribed fixes before code changes.

Updated Nov 24, 2025
One-click install
npx skills add https://github.com/ByronWilliamsCPA/.claude --skill systematic-debugging-extras
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systematic-debugging-extras
Source: https://github.com/ByronWilliamsCPA/.claude/tree/main/.claude/skills/systematic-debugging-extras
Command: npx skills add https://github.com/ByronWilliamsCPA/.claude --skill systematic-debugging-extras

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill solves the problem of wasted engineering effort and incorrect bug fixes caused by unverified root cause diagnoses and unvalidated prescribed fixes from task briefs, which often lead to changes that mask real issues or introduce new failures.

Core Features & Use Cases

  • Dual Hypothesis Verification: Validates both the stated root cause and the prescribed fix/transform before any code is written, preventing changes based on incorrect assumptions about data semantics or lever direction.
  • Scale Mismatch Detection: Identifies hidden scale mismatches (aggregate vs summed, per-unit vs total) that cause constant or all-zero metrics by instrumenting both sides of binding comparisons.
  • Shared Component Falsification: Rules out global shared component breakage by sampling 3-5 sibling consumers before building unnecessary workarounds.
  • Proxy Input Discipline: Flags findings based on proxy or stand-in data as provisional, tracks required real input artifacts, and triggers recomputation when real data becomes available.
  • Newly Reachable Path Testing: Runs end-to-end tests for code paths that become reachable only after a guard is removed, catching downstream failures that unit tests miss.
  • Use Case: When a task brief prescribes differencing a cumulative distribution to fix an all-zero metric, use this Skill to first verify the distribution is actually cumulative (not bell-shaped per-year) before applying the transform, avoiding negative distributions that corrupt economic analysis.

Quick Start

Use the systematic-debugging-extras skill alongside systematic-debugging to verify the root cause and prescribed fix for the all-zero Q3 marketing metric before implementing any changes.

Frequently Asked Questions about systematic-debugging-extras

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

FAQPage Schema
Why do my bug fixes mask real issues or introduce new failures?

Bug fixes often fail because unverified root cause diagnoses and unvalidated prescribed fixes lead to changes based on incorrect assumptions. Validating both the stated root cause and the prescribed fix before writing code eliminates wasted engineering effort and prevents incorrect bug fixes.

How do I debug all-zero or constant metrics caused by scale mismatches?

To debug all-zero or constant metrics, instrument both sides of binding comparisons to identify hidden scale mismatches such as aggregate versus summed or per-unit versus total. This scale mismatch detection prevents incorrect data transforms that corrupt downstream analysis.

What is the best way to verify a shared component failure before building a workaround?

The best way to verify a shared component failure is sibling consumer falsification, which rules out global shared component breakage by sampling 3-5 sibling consumers. This sampling prevents building unnecessary workarounds when the shared component is actually functioning correctly.

How do I validate debugging findings based on proxy input data?

To validate debugging findings based on proxy input data, flag findings as provisional, track required real input artifacts, and trigger recomputation when real data becomes available. This proxy input discipline prevents deploying fixes based on unrepresentative stand-in data.

When should I test newly reachable code paths after removing a guard?

You should test newly reachable code paths immediately after guard removal by running end-to-end tests. These tests catch downstream failures that unit tests miss, validating that removing the guard does not expose hidden defects in the newly accessible execution branches.