Use Diagnosing Bugs by Matt Pocock to investigate failures and performance regressions through a repeatable feedback loop. Reproduce the exact symptom, reduce the scenario, compare testable explanations, and verify a focused fix against both the minimized case and the original user flow.
Describe expected and actual behavior with the environment and failing input. Shape the investigation around a repeatable signal and competing causes, then require the repair to be checked on the original flow rather than judged by an unrelated successful run.
Include a reproduction, expected behavior, observed result, and relevant logs.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatPreview and copy the request. It is not sent automatically from this page.
Reference: Diagnosing Bugs https://github.com/mattpocock/skills/blob/main/skills/engineering/diagnosing-bugs/SKILL.md Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Use Diagnosing Bugs on the duplicate webhook issue. First build a repeatable signal for the duplicate charge, then investigate and verify the original scenario after fixing it. Expected deliverable: A repeatable failure signal, an evidence-based diagnosis, and verification of the original scenario.
Diagnosing Bugs is a debugging discipline in Matt Pocock’s engineering collection. It puts disproportionate effort into building a fast, repeatable pass-or-fail signal for the actual reported bug before developing theories. That signal may come from a test, HTTP request, CLI fixture, browser script, or another suitable harness. The workflow then minimizes the reproduction, ranks falsifiable hypotheses, adds targeted probes, and verifies a fix. Where a suitable testing seam exists, the reproduction becomes a regression test. The final cleanup removes temporary instrumentation and reruns the original scenario. Access to the failing environment and careful redaction of captured evidence remain important inputs.
Persistent faults, intermittent failures, and release slowdowns need different feedback signals. Explore how Diagnosing Bugs makes symptoms measurable, increases useful reproduction evidence, and checks a repair against the original input or workload.
When several patches fail to solve a bug, preserve the observed symptom and build a feedback command that catches it directly. Compare attempted fixes against that repeatable signal instead of making another guess. Use the same command to validate both the diagnosis and the final repair.
An intermittent fault needs more usable evidence before a cause is chosen. Reproduce the reported environment and run a controlled loop to increase the failure rate, preserving representative samples. Explain which conditions correlate with failure and what uncertainty remains instead of treating one successful run as a repair.
A release slowdown should be measured with the same workload and timing method before and after the change. Establish a comparable baseline, localize the regression, and retest any proposed repair on that original workload. Comparable timings make it possible to distinguish a real improvement from noise or a changed test.
The same input may succeed locally and fail under another configuration. Capture the relevant versions, settings, and observable differences, then reproduce the discrepancy with a controlled comparison. Test the suspected environmental cause before changing application logic, and rerun both cases so fixing one environment does not simply move the failure to another.
Bug diagnosis needs expected and actual behavior, an environment, and a reproducible input. Establish a reliable failure signal before comparing causes, then verify a bounded repair on the original flow and remove temporary probes when the investigation ends.
Describe the exact symptom and run a command that can detect it. Capture only the diagnostic evidence needed, with secrets removed.
Reduce inputs while preserving failure. Compare ranked hypotheses with probes that change one variable at a time.
Test the correction at an appropriate seam and rerun the original scenario. Remove debug instrumentation and record the supported cause.
Read another Skill guide and check its original source before using it.
