---
name: using-superpowers
description: Guidelines for using skills effectively - load relevant skills before complex tasks, not every message
---

# Using Skills

Skills are specialized workflows that improve quality for specific task types. Use them when they apply - don't skip them by rationalizing, but also don't invoke them ritualistically.

## When to Load a Skill

**DO load skills when:**
- Starting a complex or multi-step task
- The task clearly matches a skill's description (code review, debugging, planning, etc.)
- You're unsure how to approach something and a skill might help
- The user explicitly requests a skill-based workflow

**DON'T load skills when:**
- Answering simple questions or having conversation
- Doing trivial file reads or small edits
- The task is straightforward and no skill adds value
- You already know the skill's content from this session

## How to Use Skills

When a skill applies:

1. Load it with the Skill tool
2. Announce briefly: "Using [skill] for [purpose]"
3. If it has a checklist, create todos
4. Follow the skill's workflow

## Avoiding Common Mistakes

**Under-using skills (rationalizing):**

| Thought | Consider |
|---------|----------|
| "I'll just do this quickly" | Would a skill improve quality? |
| "This doesn't need a formal process" | Is there a skill that applies? |
| "I remember how this works" | Skills evolve - reload if unsure |
| "Let me explore first" | Some skills guide exploration |

**Over-using skills (ritual compliance):**

| Thought | Reality |
|---------|---------|
| "I must invoke skills on every message" | Only when they add value |
| "Let me check for mandatory skills" | Skills aren't rituals |
| "Confirming skill protocol compliance" | Just do the work |

## Skill Priority

When multiple skills could apply:

1. **Process skills first** (brainstorming, debugging) - these determine HOW to approach
2. **Implementation skills second** - these guide execution

Examples:
- "Let's build X" → brainstorming first, then implementation
- "Fix this bug" → debugging first, then domain-specific skills

## Skill Types

**Rigid** (TDD, debugging): Follow the process exactly.

**Flexible** (patterns): Adapt principles to context.

The skill itself indicates which type it is.

## Remember

- Skills improve quality for complex tasks
- Simple tasks don't need skill overhead
- If you're announcing "checking mandatory protocols" you've gone too far
- Just use skills naturally when they help