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 error
thought: i will inspect the recent route changes quickly before checking for skills
action: read three route files
result: no obvious bug found; start guessing at fixes
five failed fixes later: discovered the error is not in routes at all
actual 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 error
first action: invoke systematic debugging and follow its phases
phase 1: read error completely, check recent changes, instrument every boundary
observed facts: provider adapter returned dependency-unavailable
phase 2: identify where in the call stack the value corrupted
phase 3: one specific hypothesis tested once
result: 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.

search pages

go to any page