Use Systematic Debugging from Superpowers to investigate a failure before proposing repairs. Reproduce the behavior, compare working and broken paths, test a specific explanation, and verify a root-cause correction rather than stacking speculative changes on top of an unresolved problem.
Supply the full failure and a nearby working case before asking for a fix. The request can trace component boundaries and test one causal hypothesis, with the original symptom rerun after repair instead of adding another unsupported patch.
Compare working and failing environments, pipeline stages, and observed error output.
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: Systematic Debugging https://github.com/obra/superpowers/blob/main/skills/systematic-debugging/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 Superpowers Systematic Debugging for the CI-only build failure. Compare environment propagation across the pipeline before proposing a fix, then verify the original job. Expected deliverable: A root-cause investigation with tested hypotheses and a rerun of the original failing job.
Systematic Debugging is Superpowers’ root-cause investigation Skill, maintained by Jesse Vincent and the project’s contributors. Its four phases cover evidence gathering, pattern comparison, hypothesis testing, and implementation. It asks the agent to read errors, reproduce the failure, inspect recent changes, and observe data across component boundaries before choosing a fix. A small test checks one explanation at a time; the implementation stage uses a failing reproduction and verification. Repeated failed repairs call for an architectural discussion rather than another blind change. The full workflow references companion testing and completion-verification skills, and it still depends on access to the environment where the problem occurs.
Unexpected tests, broken pipeline boundaries, and unsuccessful patches need a causal explanation before another edit. Compare working cases, input/output evidence, and architectural assumptions to identify what Systematic Debugging should investigate in each situation.
An unexpected test failure needs its complete log, triggering input, and a nearby working case examined before code changes begin. Compare the two paths and test a causal explanation rather than patching the visible symptom. Rerun the original failing test after the repair to connect the explanation with observed behavior.
A pipeline failure can be localized by comparing what enters and leaves each component boundary. Collect stage parameters and upstream/downstream logs, then find the first point that diverges from expectations. Keep the input and output evidence for that boundary so the diagnosis identifies the breaking layer rather than a later symptom.
Several unsuccessful fixes are a reason to revisit assumptions, not to stack another unsupported patch. Compare what each attempt changed and what was actually observed, then discuss possible architectural causes. Reassess the structural explanation before committing to another repair that has no tested causal basis.
A failure limited to one machine or pipeline stage needs its configuration compared with a known working case. Trace the first meaningful difference and test whether it explains the symptom, retaining logs and boundary inputs. A repair should address that cause and survive a repeat of both environments instead of hiding the discrepancy with an unrelated fallback.
A systematic investigation connects accurate failure evidence with a tested explanation. Gather the reproduction context, compare normal behavior, and test one hypothesis before repairing it, then rerun the original symptom and relevant checks to establish whether the cause was addressed.
Reproduce the error, inspect recent changes, and compare a working path. Add targeted boundary observations when several components are involved.
State a specific hypothesis and use the smallest useful test. Change one variable and evaluate the result before choosing another explanation.
Capture a failing reproduction, apply the supported fix, and rerun relevant checks. Escalate repeated failures into a design discussion.
Read another Skill guide and check its original source before using it.
