obra/superpowers▌

IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

Structured debugging methodology that mandates root cause investigation before attempting any fixes. \n \n Four-phase process: root cause investigation, pattern analysis, hypothesis testing, and implementation with mandatory test cases \n Requires completing Phase 1 (evidence gathering, error analysis, data flow tracing) before proposing any fixes; blocks symptom-based patching \n Includes diagnostic instrumentation guidance for multi-component systems and backward call-stack tracing techniques

Dispatch code review subagents with focused context to catch issues before they compound. \n \n Integrates with subagent-driven development workflows, triggering review after each task or before merging to main \n Provides code-reviewer subagent with precise git SHAs, implementation details, and requirements, keeping reviewer focused on work product rather than session history \n Categorizes feedback into Critical (fix immediately), Important (fix before proceeding), and Minor (note for later) s

Execute a written implementation plan with critical review and task checkpoints. \n \n Requires loading and critically reviewing the plan before execution; raises concerns with the human partner if issues are identified \n Executes tasks sequentially, marking progress and running verifications as specified in the plan \n Stops immediately on blockers (missing dependencies, test failures, unclear instructions) rather than guessing; asks for clarification \n Integrates with git-worktrees for isola

Comprehensive implementation plans for multi-step tasks, breaking down specs into bite-sized, testable steps. \n \n Decomposes requirements into focused tasks (2–5 minutes each) following TDD: write failing test, verify failure, implement, verify pass, commit \n Maps file structure upfront with clear boundaries and responsibilities, ensuring each file has one purpose and files that change together stay together \n Includes exact file paths, complete code samples, and specific commands with expec

Dispatch fresh subagents per task with two-stage review (spec compliance, then code quality) in the current session. \n \n Isolates each task to a dedicated subagent with precisely crafted context, preventing context pollution and keeping the controller focused on coordination \n Enforces a two-stage review cycle: spec compliance reviewer confirms the implementation matches requirements, then code quality reviewer checks for issues \n Handles implementer status signals (DONE, DONE_WITH_CONCERNS,

Evaluate code review feedback with technical rigor before implementing, avoiding performative agreement and blind implementation. \n \n Verify feedback against actual codebase behavior, test coverage, and architectural context before proceeding \n Ask for clarification on unclear items before implementing anything; partial understanding leads to wrong fixes \n Push back on suggestions that break functionality, lack context, violate YAGNI, or conflict with established decisions using technical re

Isolated git worktrees with smart directory selection and safety verification. \n \n Automatically detects worktree directory location by checking existing directories, CLAUDE.md preferences, or asking the user; supports both project-local (.worktrees) and global (~/.config/superpowers/worktrees) storage \n Verifies project-local directories are git-ignored before creation to prevent accidentally committing worktree contents \n Auto-detects and runs project setup (npm install, cargo build, pip i

Delegate independent tasks to specialized agents working concurrently with isolated context. \n \n Dispatch one agent per problem domain when facing 3+ unrelated failures across different test files or subsystems \n Each agent receives focused scope, clear goal, and constraints—no inherited session context or history \n Agents work in parallel on independent investigations, then you review summaries and integrate non-conflicting fixes \n Best for timing issues, subsystem bugs, and exploratory fi

Structured workflow for completing development branches with test verification and merge/PR options. \n \n Verifies all tests pass before presenting integration options, preventing broken code from being merged or submitted \n Presents exactly four choices: merge locally, create a pull request, keep the branch as-is, or discard with confirmation \n Executes the chosen workflow, including base branch detection, git operations, and worktree cleanup \n Integrates with subagent-driven-development an

Structured design dialogue that validates ideas before implementation begins. \n \n Enforces a hard gate: no code, scaffolding, or implementation actions until design is presented and approved \n Guides through nine sequential steps: context exploration, clarifying questions, approach proposals, design presentation, spec documentation, review loop, and user sign-off \n Applies to all projects regardless of perceived complexity; even simple tasks require a brief design review to catch unexamined

Enforce verification commands before claiming work completion, fixes, or test passes—no success assertions without fresh evidence. \n \n Requires running the actual verification command (not assumptions or partial checks) and confirming output before making any completion or correctness claims \n Applies to all success-related statements: test passes, builds succeeding, bugs fixed, requirements met, regressions verified, and agent task completion \n Blocks common shortcuts like trusting agent re

Write tests first, watch them fail, then implement minimal code to pass. \n \n Follows the red-green-refactor cycle: write a failing test, verify it fails correctly, implement minimal code to pass, then refactor while keeping tests green \n Requires deleting any production code written before tests exist; no exceptions for \"reference\" or \"adaptation\" \n Emphasizes watching tests fail as proof they actually test the right thing; tests that pass immediately prove nothing \n Covers common ratio

$22