ptp-systematic-debugging

Diagnose bugs through reproduction, evidence collection, and root-cause isolation before fixing.

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/AlmogMaayan/ptp --skill ptp-systematic-debugging-almogmaayan
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ptp-systematic-debugging
Source: https://github.com/AlmogMaayan/ptp/tree/main/skills/ptp-systematic-debugging
Command: npx skills add https://github.com/AlmogMaayan/ptp --skill ptp-systematic-debugging-almogmaayan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents premature fixes by enforcing a disciplined debugging sequence: no change is proposed until the failure is reproduced and its root cause is named, eliminating symptom-masking patches and stacked guesswork. ## Core Features & Use Cases - Six-step root-cause workflow: Reproduce with a deterministic trigger, collect evidence, isolate the failing boundary, test one hypothesis at a time, fix the root cause, and add a regression check. - Hypothesis discipline: One variable at a time, never stacked fixes, and a hard stop after three failed hypotheses to question the design instead. - Current-state recording: The durable record carries only the reproduction, evidence, root cause, fix, and regression check — no investigation diary. - Use Case: An intermittent production failure tempts a quick retry patch before a deadline; the skill requires reproducing the failure and naming the cause, shipping a retry only as a labelled mitigation for an external cause. ## Quick Start Debug this failing test by first reproducing it, isolating the failing boundary, and identifying the root cause before proposing any fix.

Frequently Asked Questions about ptp-systematic-debugging

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

FAQPage Schema
How do I debug a bug systematically instead of guessing fixes?

Follow a six-step sequence: reproduce the failure with a deterministic trigger, collect evidence from errors and stack traces, isolate the single failing boundary, test one hypothesis at a time, fix the root cause, and add a regression check. No fix is proposed before the root cause is named.

How to handle an intermittent bug that cannot be reproduced?

Gather data until the failure becomes reproducible rather than guessing at a fix. Instrument the boundaries between components and record what enters and leaves each until a deterministic trigger emerges.

When is a symptom-level workaround acceptable instead of a root-cause fix?

A symptom-level mitigation is permitted only when the root cause is external and unreachable. It must be explicitly labelled as a mitigation with the named cause recorded, never presented as a fix.

What should I do after several debugging hypotheses fail?

After three failed hypotheses, stop and question the design instead of attempting a fourth fix. A disproved hypothesis leads to a new hypothesis, never to stacked fixes applied together.

Why should a regression test be added after fixing a bug?

A regression check proves the fix by failing on the original defect and passing after it. It prevents the defect from silently returning and provides recorded evidence that the root cause was actually addressed.