// Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
Use EVERY TIME you need to run tests, verify tests pass, or check for regressions. ALWAYS use this instead of running eldev directly.
Use when code quality needs improvement after implementation, without changing behavior
Use when implementation is complete and you want to verify quality through adversarial testing that writes code and provides evidence
Use when a design exists and it's time to break it into tasks and execute with subagent dispatch and review
Use when requirements exist and a technical design is needed before implementation begins
Use when a new feature request, bug report, or work request needs requirements defined before implementation
| name | using-superpowers |
| description | Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions |
IF A SKILL APPLIES TO YOUR TASK, YOU MUST USE IT.
This is not negotiable. This is not optional. You cannot rationalize your way out of this.
Check for skills BEFORE ANY RESPONSE. This includes clarifying questions. Even 1% chance means invoke the Skill tool first.
These skills form a pipeline. Each phase produces a dated artifact and references the next step:
| Skill | When to Use |
|---|---|
/define | New feature request, bug report, or requirement to break down |
/architect | Requirements exist, need technical design |
/implement | Design exists, ready to build |
/qa | Implementation complete, need adversarial testing |
/refactor | Code quality pass after implementation |
You don't always need all phases. Start at whichever phase makes sense.
These thoughts mean STOP — you're rationalizing:
| Thought | Reality |
|---|---|
| "This is just a simple question" | Questions are tasks. Check for skills. |
| "I need more context first" | Skill check comes BEFORE clarifying questions. |
| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
| "This doesn't need a formal skill" | If a skill exists, use it. |
| "The skill is overkill" | Simple things become complex. Use it. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
When multiple skills could apply:
Rigid (TDD, qa): Follow exactly. Don't adapt away discipline.
Flexible (patterns): Adapt principles to context.
The skill itself tells you which.
Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.
