mighty-powers

Mighty Powers

Unified Claude Code plugin for full-lifecycle software development. Combines the best of Superpowers, Ultraship, and BMAD Method into a single coherent plugin.

Quick Start

claude plugin marketplace add anderson-0/mighty-powers
claude plugin install mighty-powers

For local development from a clone, use claude plugin marketplace add ./mighty-powers instead of the GitHub slug above.

Then in your project:

/mp:init  # first-time setup: config, CLAUDE.md, directory structure

What's Included

• 54 skills covering analysis, planning, solutioning, implementation, auditing, and deployment
• 22 Node.js tools for security scanning, code profiling, architecture mapping, and more
• 6 named agents (Reese, Sasha, Winston, Jordan, Quinn, Morgan) for reviews, audits, and multi-agent discussions
• 34 slash commands for quick access to common workflows
• Safety guardrails that block destructive commands automatically
• Session resilience — if your IDE crashes, /resume picks up exactly where you stopped
• Wave-based execution — plans organized into waves with checkpoints; independent tasks within a wave run in parallel

---

How Routing Works

When you give Claude a task, it follows a decision tree to pick the right level of process. It defaults to the lightest approach that fits. It will never use heavyweight BMAD lifecycle planning for a simple feature unless you explicitly ask for it.

You give a task
  │
  ├─ Bug fix? → /investigate (4-phase root cause) → fix with appropriate tier
  │
  ├─ You explicitly ask for PRD, architecture, or epics?
  │   → Lifecycle Track (formal planning)
  │
  ├─ New project with unclear scope?
  │   → Claude asks: "Structured planning or jump straight in?"
  │
  ├─ Trivial? (typo, config, < 20 lines)
  │   → Claude asks: "Jump in or plan first?"
  │     ├─ Jump in → TDD → verification
  │     └─ Plan first → treated as Small tier
  │
  ├─ Small? (clear scope, < 100 lines)
  │   → /write-plan → /execute-plan → verification
  │
  ├─ Medium? (single feature, multiple files)
  │   → /brainstorm → /write-plan → /execute-plan → /review
  │
  └─ Needs spec tracking across sessions?
      → /quick-dev (5-step with adversarial review + spec file)

The key principle: pick the smallest tier that fits. You can always escalate mid-task if the work turns out to be bigger than expected.

---

How Planning Works

Every implementation plan — regardless of size — is organized into waves. This is the core execution model.

What is a wave?

A wave groups tasks at the same dependency level — they all depend on the same set of prior tasks being done. Tasks within a wave MAY be independent (different files, no shared state → run in parallel) or they may need sequential execution (shared files, ordering requirements). Between waves, there is a checkpoint where all tests must pass before proceeding.

Not every wave has parallelism. A wave with a single task is perfectly normal. A fully sequential plan (one task per wave) is also fine — waves still provide checkpoints and clear dependency ordering.

How plans get decomposed into waves

1. All tasks are identified from the spec/requirements
2. A dependency graph is built: which tasks depend on which?
3. Tasks are grouped by dependency level:
   • Wave 1: Tasks with no dependencies (foundations, types, interfaces, schemas)
   • Wave 2: Tasks that depend only on Wave 1 outputs
   • Wave 3: Tasks that depend on Wave 2 outputs
4. Within each wave, tasks are checked for independence (different files, no shared state = parallel; shared files = sequential)
5. Parallelism is maximized: if a task can move to an earlier wave, it does

Example plan structure

Feature: Add webhook retry logic

Wave 1: Foundation (3 independent tasks → parallel)
  Task 1.1: Define retry config schema and types
  Task 1.2: Create retry queue interface
  Task 1.3: Add retry-related database migrations
  → Checkpoint: run full test suite

Wave 2: Core Logic (2 independent tasks → parallel)
  Task 2.1: Implement exponential backoff retry strategy
  Task 2.2: Implement dead letter queue for failed webhooks
  → Checkpoint: run full test suite

Wave 3: Integration (1 task)
  Task 3.1: Wire retry logic into existing webhook dispatcher
  → Checkpoint: run full test suite

What each task contains

Every task is self-contained — a subagent reading only that task has everything it needs: