using superpowers
the gateway discipline of the superpowers system: check for a relevant skill before doing anything else — before answering, before asking clarifying questions, before exploring files.
what it teaches
- skills are process knowledge encoded ahead of time; invocation order is what makes them work: skill check first, action second.
- exploring "quickly" first means the agent already chose an approach without the guidance that existed for exactly that situation.
why it exists
the failure mode is rationalized skipping — "This is just a simple question," "I need more context first," "the skill is overkill." each thought feels reasonable in isolation and each bypasses the discipline. naming the rationalizations makes them visible at the moment they occur.
the rules
- if there is even a 1% chance a skill applies, invoke it.
- announce the skill, then follow it exactly. if it turns out wrong for the situation, you don't have to keep using it — but you must check.
- process skills come before implementation skills. Brainstorming and systematic-debugging set the approach; design and tooling skills carry it out.
- user instructions outrank skills; skills outrank default behavior.
when to use
- continuously: at the start of every task, and again whenever task scope changes.
- red-flag self-test that the discipline is still active: "I'll just check one thing first."
good and bad
bad
task: diagnose a production errorthought: i will inspect the recent route changes quickly before checking for skillsaction: read three route filesresult: no obvious bug found; start guessing at fixesfive failed fixes later: discovered the error is not in routes at allactual cause: database query timed out (found via instrumented boundaries)
skipping the skill check runs a local, intuitive approach instead of a systematic one. unstructured inspection misses layers; every wrong guess delays the investigation and compounds with previous wrong fixes. the discipline also erodes silently: each "just one quick look" makes the next skip easier, until process knowledge exists on disk but never loads.
good
task: diagnose a production errorfirst action: invoke systematic debugging and follow its phasesphase 1: read error completely, check recent changes, instrument every boundaryobserved facts: provider adapter returned dependency-unavailablephase 2: identify where in the call stack the value corruptedphase 3: one specific hypothesis tested onceresult: root cause found on first systematic check, one targeted fix
the process skill determines the investigation before implementation habits do — no thrashing, root causes found faster. over a session the ordering compounds: every task starts from encoded process instead of re-derived intuition, so the quality floor holds even under pressure.