---

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 DO NOT HAVE A CHOICE. 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.

Copydigraph skill_flow {
    "User message received" [shape=doublecircle];
    "Might any skill apply?" [shape=diamond];
    "Invoke Skill tool" [shape=box];
    "Announce: 'Using [skill] to [purpose]'" [shape=box];
    "Has checklist?" [shape=diamond];
    "Create bd issues for checklist items" [shape=box];
    "Follow skill exactly" [shape=box];
    "Respond (including clarifications)" [shape=doublecircle];

    "User message received" -> "Might any skill apply?";
    "Might any skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"];
    "Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
    "Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'";
    "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
    "Has checklist?" -> "Create bd issues for checklist items" [label="yes"];
    "Has checklist?" -> "Follow skill exactly" [label="no"];
    "Create bd issues for checklist items" -> "Follow skill exactly";
}

Red Flags

These thoughts mean STOP—you're rationalizing:

Skill Priority

When multiple skills could apply, use this order:

1. Process skills first (brainstorming, debugging) - these determine HOW to approach the task
2. Implementation skills second (frontend-design, mcp-builder) - these guide execution

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

Skill Types

Rigid (TDD, debugging): Follow exactly. Don't adapt away discipline.

Flexible (patterns): Adapt principles to context.

The skill itself tells you which.

BD Integration for Checklists

When a skill contains a checklist, create bd issues to track completion:

Copy# Example: Writing a skill with checklist
bd create "RED Phase: Create pressure scenarios" --type task --priority 1
bd create "RED Phase: Run baseline tests" --type task --priority 1 --deps blocks:<previous-id>
bd create "GREEN Phase: Write minimal skill" --type task --priority 1 --deps blocks:<previous-id>
bd create "REFACTOR Phase: Close loopholes" --type task --priority 1 --deps blocks:<previous-id>
bd create "Quality: Add CSO keywords" --type task --priority 2
bd create "Deploy: Commit and push" --type task --priority 2 --deps blocks:<all-previous>

# Track progress
bd list --status open
bd update <id> --status in_progress
bd close <id>

Benefits of bd for checklists:

• Persistence: Checklist survives session interruptions
• Dependencies: Enforce proper ordering
• Visibility: See what's been done and what remains
• Notes: Add context with bd comment

User Instructions

Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.