using-superpowers

<EXTREMELY-IMPORTANT> If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST read the skill.

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. </EXTREMELY-IMPORTANT>

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:

1. Process skills first (define, architect) — determine HOW to approach
2. 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.