> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/obra/superpowers/llms.txt
> Use this file to discover all available pages before exploring further.

# Using Superpowers

> Learn how to effectively use the Superpowers skills system

## Overview

The `using-superpowers` skill establishes the fundamental rule for working with the Superpowers framework: **invoke relevant skills BEFORE any response or action**.

<Note>
  This skill is automatically loaded at session start via the SessionStart hook, making it the foundation of the entire skills system.
</Note>

## The Core Rule

**If there's even a 1% chance a skill might apply to your task, you MUST invoke it.**

This is not negotiable. This is not optional. Skills are not suggestions—they're mandatory workflows that ensure systematic, high-quality development.

## How Skills Are Loaded

### Claude Code

Use the `Skill` tool to load skills. When invoked, the skill content is loaded and presented—follow it directly. Never use the Read tool on skill files.

### Other Platforms

Check your platform's documentation for how skills are loaded (typically through skill directories or plugin systems).

## Skill Invocation Flow

The decision flow for using skills:

<Steps>
  <Step title="Receive User Message">
    A new message arrives or you're about to enter plan mode.
  </Step>

  <Step title="Check for Applicable Skills">
    Ask yourself: "Might any skill apply to this task?" Even 1% probability means YES.
  </Step>

  <Step title="Invoke the Skill">
    Use the Skill tool (or platform equivalent) to load the relevant skill.
  </Step>

  <Step title="Announce Usage">
    Tell the user: "Using \[skill name] to \[purpose]"
  </Step>

  <Step title="Create Task List">
    If the skill has a checklist, create TodoWrite items for each step.
  </Step>

  <Step title="Follow Exactly">
    Execute the skill's instructions precisely.
  </Step>
</Steps>

## Red Flags: Stop Rationalizing

These thoughts indicate you're trying to skip skills—STOP:

<Warning>
  **Common Rationalizations:**

  | 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.       |
  | "I can check git/files quickly"     | Files lack conversation context. Check for skills. |
  | "This doesn't need a formal skill"  | If a skill exists, use it.                         |
  | "I remember this skill"             | Skills evolve. Read current version.               |
  | "The skill is overkill"             | Simple things become complex. Use it.              |
  | "I'll just do this one thing first" | Check BEFORE doing anything.                       |
  | "This feels productive"             | Undisciplined action wastes time.                  |
  | "I know what that means"            | Knowing the concept ≠ using the skill.             |
</Warning>

## Skill Priority

When multiple skills could apply:

1. **Process skills first** (brainstorming, debugging) — Determine HOW to approach the task
2. **Implementation skills second** (domain-specific guides) — Guide execution

**Examples:**

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

## Skill Types

### Rigid Skills

Skills like TDD and debugging must be followed exactly. Don't adapt away the discipline—that's the point.

### Flexible Skills

Pattern-based skills provide principles you adapt to context.

The skill itself indicates which type it is.

## User Instructions

User instructions say WHAT to do, not HOW. "Add feature X" or "Fix bug Y" doesn't mean skip workflows—it means use the appropriate skills to accomplish the goal systematically.

## EnterPlanMode Intercept

Before entering Claude's native plan mode, the system checks:

* Has brainstorming happened?
* If not, route through the **brainstorming** skill instead

This ensures design happens before implementation, even when the model wants to jump straight to planning.

## Why This Matters

Without systematic skill usage:

* Designs get skipped, leading to wasted implementation effort
* Tests get written after code, proving nothing
* Debugging becomes guess-and-check
* Code reviews happen haphazardly
* Technical debt accumulates

With systematic skill usage:

* Every feature starts with validated design
* TDD catches bugs before they exist
* Debugging is root-cause analysis
* Reviews have consistent quality gates
* Code quality stays high

## Related Skills

* [Brainstorming](/skills/brainstorming) - The most commonly triggered process skill
* [Test-Driven Development](/skills/test-driven-development) - Example of a rigid skill
* [Systematic Debugging](/skills/systematic-debugging) - Example of a process-first skill
* [Writing Skills](/skills/writing-skills) - For creating new skills