By 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.
Using Skills
The Rule
Check for skills BEFORE ANY RESPONSE. This includes clarifying questions. Even 1% chance means invoke the Skill tool first.
Development Workflow Skills
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.
Red Flags
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. |
Skill Priority
When multiple skills could apply:
- Process skills first (define, architect) — determine HOW to approach
- Implementation skills second (implement, qa, refactor) — guide execution
Skill Types
Rigid (TDD, qa): Follow exactly. Don't adapt away discipline.
Flexible (patterns): Adapt principles to context.
The skill itself tells you which.
User Instructions
Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.