using-superpowers skill
Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions
Is the using-superpowers skill safe?
Clean: nothing in its files matched our rules. We read 8 files in the folder on 2026-10-25.
No findings.
Install the using-superpowers skill
A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.
git clone --depth 1 https://github.com/obra/superpowers.git /tmp/superpowers mkdir -p ~/.claude/skills cp -r /tmp/superpowers/skills/using-superpowers ~/.claude/skills/using-superpowers
In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub
The instructions your agent would load
SKILL.md as published, without the frontmatter. Read it on GitHub
If you were dispatched as a subagent to execute a specific task, ignore this skill.
If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. You cannot rationalize your way out of this.
The Rule
Invoke relevant or requested skills BEFORE any response or action — including clarifying questions, exploring the codebase, or checking files. If it turns out wrong for the situation, you don't have to use it.
Before entering plan mode: if you haven't already brainstormed, invoke the brainstorming skill first.
Then announce "Using [skill] to [purpose]" and follow the skill exactly. If it has a checklist, create a todo per item.
Skill Priority
When multiple skills apply, process skills come first — they set the approach, then implementation skills (frontend-design, etc.) carry it out. Brainstorming and systematic-debugging are Superpowers' most common process skills, but the rule holds for any of them.
- "Let's build X" → superpowers:brainstorming first, then implementation skills.
- "Fix this bug" → superpowers:systematic-debugging first, then domain skills.
Red Flags
These thoughts mean STOP—you're rationalizing:
Platform Adaptation
If your harness appears here, read its reference file for special instructions:
- Claude Code: references/claude-code-tools.md
- Codex: references/codex-tools.md
- Pi: references/pi-tools.md
- Antigravity: references/antigravity-tools.md
- Hermes Agent: references/hermes-tools.md
- Muse: references/muse-tools.md
User Instructions
User instructions (CLAUDE.md, AGENTS.md, GEMINI.md, etc, direct requests) take precedence over skills, which in turn override default behavior. Only skip skill workflows or instructions when your human partner has explicitly told you to.
More skills from obra/superpowers
- AbrainstormingYou MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
- Adiagnosing-superpowersUse when a superpowers session went wrong and your human partner wants to know why — repeated work, ignored plans, stumbles, poor results, a skill that didn't fire, "it took too long", "why is it so expensive", "what is it doing" — or wants to build a bug report for the superpowers maintainers, for the current session or a past one identified by id or path, on any harness.
- Adispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
- Aexecuting-plansUse when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
- Afinishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work
- Areceiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
- Arequesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirements
- Asubagent-driven-developmentUse when executing implementation plans with independent tasks in the current session
- Asystematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixes
- Atest-driven-developmentUse when implementing any feature or bugfix, before writing implementation code
- Ausing-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
- Averification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always