Menu
Use when a bug, test failure, or unexpected behaviour appears, to find the root cause before changing code instead of guessing fixes. A four-phase process that stops the hallucinated-fix loop and the token waste of trying patches at random.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when several pieces of work are genuinely independent and can run at once, to fan them out across parallel agents instead of doing them in sequence. Cuts wall-clock time and keeps each strand in its own clean context.
Use when a written plan exists and you are about to build it in the current session, to work it task by task with a checkpoint after each. Keeps execution honest against the plan instead of drifting into a freehand build.
Use when work needs its own isolated checkout — parallel strands that would fight over files, or a risky change you want quarantined from the main tree. Gives each strand a real working directory on its own branch without re-cloning.
Use whenever the user says "use slipstream", "use superpowers", or starts any task in a project that has slipstream. A hard, always-on discipline that forces scoped reads over whole-file reads to save tokens, recalls memory before acting, and records what is durable every turn so memory grows constantly.
Use when a site needs to look designed rather than defaulted, before building sections: establish a cohesive design system of type scale, spacing, colour, radius and shadow tokens so every component shares one premium visual language.
Use when building the top of a landing page, to produce a high-impact hero with confident display type, a clear single call to action and balanced composition, the kind of opening a polished marketing site leads with.
| name | systematic-debugging |
| description | Use when a bug, test failure, or unexpected behaviour appears, to find the root cause before changing code instead of guessing fixes. A four-phase process that stops the hallucinated-fix loop and the token waste of trying patches at random. |
| slipstream | {"category":"context","requires":[],"tags":["debugging","discipline","token-efficiency"]} |
The expensive failure mode in debugging is fixing a symptom you do not understand: you change a line, the error moves, you change another, and three turns later the budget is gone and the bug is still there. This skill enforces root-cause-first. You do not edit production code until you can explain why the bug happens. The cost is a little patience up front; the saving is the pile of speculative edits you never make.
Four phases, in order — do not skip ahead:
sp_search and sp_symbol to read the relevant code precisely rather than loading whole files.The previously failing case now passes, the tests around it still pass, and you can state in one sentence why the bug happened and why the fix addresses that cause. A fix you cannot explain is not verified — keep going.