| name | using-mighty-powers |
| description | Use when starting any conversation — establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions |
If you were dispatched as a subagent to execute a specific task, skip this skill.
**Memory-first rule:** At the START of every session, read MEMORY.md and relevant memory files BEFORE performing any task. Never claim something is missing or not done without first checking memory. Memory records can become stale — verify against current state before acting on them.
**Currency-first rule:** Do not answer version-sensitive questions from training data — library/SDK APIs, package versions, model IDs, pricing, CLI flags, "latest" anything. Verify against current sources first: context7 MCP for library docs, WebSearch/WebFetch for everything else, the project lockfile for installed versions. The `mp:staying-current` skill is the full policy. The Currency Guard hook will remind you when a prompt looks version-sensitive. If you can't verify, say so rather than guessing.
**Skill-first rule:** Invoke relevant skills BEFORE any response or action — including clarifying questions. Even a 1% chance a skill might apply means invoke it first. If an invoked skill turns out not to fit, you don't need to follow it. Skipping a skill and being wrong costs more than invoking one unnecessarily.
Instruction Priority
Mighty Powers skills override default system prompt behavior, but user instructions always take precedence:
- User's explicit instructions (CLAUDE.md, direct requests) — highest priority
- Mighty Powers skills — override default system behavior where they conflict
- Default system prompt — lowest priority
How to Access Skills
In Claude Code: Use the Skill tool. When you invoke a skill, its content is loaded and presented to you—follow it directly. Never use the Read tool on skill files.
ROUTING: The Most Important Section
Mighty Powers has 3 tracks. You MUST pick the right track based on the task. Getting this wrong means either wasting the user's time with overkill process OR shipping sloppy work without enough discipline.
Default to the Quick Track. Only escalate to Lifecycle Track when the user explicitly asks for it or the task genuinely requires multi-epic planning.
Track 1: Quick Track (use 80% of the time)
For: Bug fixes, single features, refactors, small-to-medium changes, anything with clear scope.
How to recognize: The user says "add X", "fix Y", "change Z", "implement this feature", or describes a single clear task.
Quick Track has 4 size tiers. Pick the smallest tier that fits the task.
Tier 1: Trivial (fix a typo, change a config value, rename something)
Ask the user before skipping planning:
"This looks like a quick change. Want me to jump straight to implementation, or would you prefer an implementation plan first?"
If user says jump in:
- Use
mp:test-driven-development — write a test if applicable, make the change
- Use
mp:verification — run tests, confirm everything passes
If user wants a plan → treat as Tier 2.
Tier 2: Small (clear scope, < 100 lines, one file or a few files)
Planning required. Plan is organized in waves with checkpoints.
writing-plans → executing-plans (wave by wave) → verification
- Use
mp:writing-plans — create plan organized into waves (parallel where tasks are independent, sequential where they're not)
- Use
mp:executing-plans or mp:subagent-driven-development — execute wave by wave, parallelize independent tasks within each wave
- Use
mp:verification — run tests, confirm complete
Tier 3: Medium (single feature, clear scope, multiple files)
Full Quick Track with optional design exploration. Plan organized in waves.
brainstorming → writing-plans (waves) → executing-plans (wave by wave) → code-review → verification
↑
(skip if
scope is
obvious)
mp:brainstorming — only if the approach isn't obvious. Skip if you know what to build. (Quick Track design-with-approval; for Lifecycle ideation use mp:brainstorm-session instead.)mp:writing-plans — detailed plan structured in waves with checkpoints (parallel where tasks are independent)mp:executing-plans or mp:subagent-driven-development — execute wave by wave, parallelize independent tasksmp:code-review — two-stage review before mergemp:verification — final check
Tier 4: Structured Small (needs spec tracking across sessions)
For when the change is small but you need a formal spec document — e.g., the work will span multiple sessions, or you want adversarial review of the approach before coding.
quick-dev (5-step workflow with spec file, wave-based plan)
- Use
mp:quick-dev — clarify intent → plan (in waves) → implement (parallel per wave) → adversarial review → present
- This creates a spec file in
docs/implementation/ that tracks progress
Use Tier 4 only when Tier 2-3 isn't enough — when you need the spec as a persistent artifact.
Wave-Based Execution (applies to all tiers with plans)
All implementation plans are organized into waves. Each wave groups tasks at the same dependency level. Tasks within a wave that are independent (different files, no shared state) run in parallel via subagents. Tasks that share files or have ordering requirements run sequentially within the wave. Between waves, there is a checkpoint.
Wave 1: [Task A] [Task B] [Task C] ← independent → run in parallel
↓ checkpoint
Wave 2: [Task D] → [Task E] ← D and E share a file → run sequentially
↓ checkpoint
Wave 3: [Task F] ← single task
Not every wave has parallelism. A plan that is entirely sequential (one task per wave) is fine — waves still provide checkpoints and clear dependency ordering. See mp:writing-plans for how plans are structured.
Bug fixes at any size
Always start with mp:systematic-debugging — 4-phase root cause process. Then apply the appropriate tier above for the fix.
Supporting skills (available in all tiers)
| Phase | Skill | When |
|---|
| BUILD | mp:test-driven-development | During ANY code writing — write test first, then code |
| BUILD | mp:systematic-debugging | ANY bug or unexpected behavior — root cause first |
| BUILD | mp:git-worktrees | When you need an isolated workspace |
| VERIFY | mp:finishing-branch | When branch is ready to merge/PR |
| BUILD | mp:dispatching-parallel-agents | When a user request OR plan has 2+ independent tasks — dispatch in parallel, not sequentially |
Track 2: Lifecycle Track (use only when needed)
For: New projects from scratch, multi-epic features, unclear/complex scope, team handoff artifacts.
How to recognize: The user says "build a new app", "design the architecture for X", "create a PRD", "plan out this large initiative", or explicitly asks for structured planning artifacts. The work will span multiple sessions or involve multiple developers.
DO NOT use Lifecycle Track skills unless:
- The user explicitly requests them (e.g., "create a PRD", "design the architecture")
- OR the task genuinely requires multi-epic planning (3+ distinct features that must be coordinated)
- OR the user asks to "start from scratch" on a new project
"Add a login page" is Quick Track, not Lifecycle. "Build a complete authentication system with OAuth, MFA, session management, and admin panel" MIGHT be Lifecycle if the user wants formal planning.
When in doubt, start with Quick Track. You can always escalate later.
Flow:
Analysis → Planning → Solutioning → Implementation
↓ ↓ ↓ ↓
research prd architecture dev-story
product- create-ux create-epics sprint-planning
brief design check-ready sprint-status
prfaq gen-context checkpoint-preview
brainstorm-session
Skills in this track:
| Phase | Skill | When |
|---|
| Analysis | mp:brainstorm-session | Lifecycle ideation — creative techniques, memlog, resume |
| Analysis | mp:research | Validate assumptions with domain/market/technical research |
| Analysis | mp:product-brief | Capture strategic vision |
| Analysis | mp:document-project | Document an existing project |
| Analysis | mp:prfaq | Working Backwards PRFAQ — stress-test product concepts |
| Planning | mp:prd | Create, update, or validate a PRD (unified workflow) |
| Planning | mp:create-ux-design | UX design — DESIGN.md + EXPERIENCE.md spines |
| Solutioning | mp:architecture | Architecture spine — invariants that keep work consistent |
| Solutioning | mp:create-epics | Break requirements into epics and stories |
| Solutioning | mp:generate-project-context | Generate project "constitution" |
| Solutioning | mp:check-readiness | Gate check before implementation |
| Implementation | mp:sprint-planning | Generate sprint-status.yaml from epics |
| Implementation | mp:sprint-status | Summarize sprint status and recommend next action |
| Implementation | mp:create-story | Prepare next story |
| Implementation | mp:dev-story | Execute a story (uses TDD internally) |
| Implementation | mp:checkpoint-preview | Human-in-the-loop review of a change |
| Implementation | mp:qa-generate-e2e-tests | Generate API/E2E tests for implemented code |
| Management | mp:sprint | Quick Track pipeline: plan → build → test → review → ship |
| Management | mp:retrospective | Sprint retrospective |
| Management | mp:correct-course | Mid-sprint pivots |
Deprecated shims (redirect to skills above): create-prd, validate-prd, create-architecture.
You don't need ALL phases. If the user already has a PRD, skip to Solutioning. If they already have architecture + epics, skip to Implementation.
Track 3: Audit Track (on-demand)
For: Quality gates, security checks, pre-deploy verification, incidents. These are invoked explicitly or at natural checkpoints, not as part of a development flow.
| Phase | Skill | When |
|---|
| VERIFY | mp:guard | Manage safety guardrails, freeze directories |
| REVIEW | mp:security-audit | User asks to audit security, or before shipping sensitive changes |
| REVIEW | mp:pentest | User asks for penetration testing |
| SHIP | mp:ship | Pre-deploy scorecard — user asks "are we ready to ship?" |
| DEFINE | mp:architecture-map | User asks for architecture diagrams |
| SHIP | mp:rescue | Production incident — diagnostics, rollback, post-mortem |
Track 4: Knowledge & Advanced (on-demand)
| Skill | When |
|---|
mp:staying-current | Before answering anything version-sensitive — library APIs, versions, pricing, model IDs |
mp:learnings | User wants to save/search/digest/recall project learnings |
mp:onboard | User asks for an onboarding guide |
/codex command | Generate compact codebase index at .mighty-powers/codex.md to save exploration tokens |
mp:revise-claude-md | User asks to update CLAUDE.md |
mp:party-mode | User asks for a multi-agent discussion |
mp:advanced-elicitation | User wants to push output quality |
mp:adversarial-review | User wants a cynical review of a plan/document |
mp:grilling | User wants to stress-test a plan/decision — relentless one-at-a-time questioning |
mp:writing-skills | User wants to create new skills |
mp:resume | Resume an interrupted plan after session crash — auto-detects or point to plan folder |
mp:status | Check plan progress without resuming — read-only view of where things stand |
mp:init | First-time project setup — creates config, offers to generate CLAUDE.md |
mp:help | User asks for help or "what should I do next?" |
Routing Decision Tree
When a user gives you a task, follow this decision tree:
Session starts
│
├─ Session-start hook detected an in-progress plan?
│ └─ YES → Tell the user:
│ "Found in-progress plan: <name> (wave N). Want to resume?"
│ ├─ Yes → /resume
│ └─ No → "Want me to mark this plan as abandoned so I don't ask again?"
│ ├─ Yes → Update status.yaml: status → abandoned
│ └─ No → Leave as-is (will ask again next session)
│
User gives a task
│
├─ Is it a bug fix or unexpected behavior?
│ └─ YES → mp:systematic-debugging → then fix using appropriate tier
│
├─ Is it a question, research, or exploration?
│ └─ YES → Answer directly (no skill needed) unless user asks for formal research
│
├─ Does the user explicitly ask for a PRD, architecture, epics, or lifecycle planning?
│ └─ YES → Lifecycle Track (Track 2)
│
├─ Is it a new project from scratch with unclear scope?
│ └─ YES → Ask the user: "Do you want structured planning (PRD, architecture, epics)
│ │ or jump straight to implementation?"
│ │ ├─ Structured → Lifecycle Track
│ │ └─ Jump in → Quick Track Tier 3 (brainstorming first)
│
├─ Is it trivial? (typo, config change, rename, < 20 lines)
│ └─ YES → Quick Track Tier 1: Ask user "jump in or plan first?"
│
├─ Is it small? (clear scope, < 100 lines, few files)
│ └─ YES → Quick Track Tier 2: writing-plans → executing-plans → verification
│
├─ Is it a single feature? (clear scope, multiple files)
│ └─ YES → Quick Track Tier 3: brainstorming? → writing-plans → executing-plans
│ → code-review → verification
│
├─ Does it need a persistent spec artifact? (multi-session, needs adversarial review)
│ └─ YES → Quick Track Tier 4: mp:quick-dev
│
└─ Default → Quick Track Tier 2 or 3 based on scope
Key principle: pick the smallest tier that fits. You can always escalate mid-task if the work turns out to be bigger than expected.
Using Skills
The Rule
Invoke the skill for the CORRECT TRACK before any response or action. The routing decision tree above determines which skill to invoke. Do not invoke Lifecycle Track skills for Quick Track tasks.
Red Flags
These thoughts mean STOP—you're making a routing error:
| Thought | Reality |
|---|
| "Let me create a PRD for this bug fix" | Bug fix = Quick Track. Use systematic-debugging. |
| "I should create architecture docs for this feature" | Single feature = Quick Track unless user asks for it. |
| "Let me break this into epics" | Epics are Lifecycle Track. Single feature just needs writing-plans. |
| "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. |
| "This is just a simple question" | Questions are tasks. Check for applicable skills. |
| "I remember this skill" | Skills evolve. Read current version. |
| "The skill is overkill" | Use the RIGHT track, not the BIGGEST track. Quick Track is not overkill. |
| "I'll just do this one thing first" | Check routing BEFORE doing anything. |
Skill Types
Rigid (TDD, debugging, guard): Follow exactly. Don't adapt away discipline.
Flexible (brainstorming, patterns): Adapt principles to context.
User Instructions
Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows — but it also doesn't mean escalate to Lifecycle Track.
Agent Orchestration
Many skills dispatch specialized subagents for review, audit, or parallel work. This is a core strength of the plugin — use it whenever possible to improve quality and speed.
Standard Dispatch Pattern
Use Claude Code's built-in Agent tool to dispatch subagents:
Agent tool call:
prompt: [Agent role instructions from agents/<name>.md] + [Task-specific context]
description: Short label (e.g., "security audit", "code review")
model: Choose based on task complexity (see below)
Parallel Dispatch
When multiple agents are independent, dispatch them all in a single response so they run concurrently:
Single message with multiple Agent tool calls:
Agent 1: security-auditor → scans for vulnerabilities
Agent 2: code-reviewer → reviews code quality
Agent 3: bundle audit → checks build size
All three run in parallel. Collect results when all complete.
Model Selection
Use the least powerful model that can handle the role:
| Task Type | Model | Examples |
|---|
| Fast/mechanical | haiku | Bundle size check, secret scanning, pattern matching |
| Standard reasoning | sonnet | Code review, security audit, test generation |
| Deep judgment | opus | Architecture review, design decisions, complex debugging |
Pass the model via the Agent tool's model parameter.
Shared Agent Definitions
Reusable agent prompts live in agents/:
| Agent | Use For |
|---|
agents/code-reviewer.md | Two-stage code review (spec + quality) with confidence scoring |
agents/security-auditor.md | 8-category security audit |
agents/architect.md | Architecture review and ADR recommendations |
agents/product-manager.md | PRD review and requirements validation |
agents/qa-engineer.md | Test coverage review and test strategy |
agents/incident-responder.md | Incident diagnosis, rollback planning, post-mortem |
When a skill dispatches a subagent, it reads the agent definition and includes it in the prompt along with task-specific context. The subagent never inherits the parent session's history.
Skills That Orchestrate Agents
| Skill | Agents Dispatched | Pattern |
|---|
code-review | code-reviewer | Single agent dispatch after implementation |
ship | security-auditor + code-reviewer + bundle auditor | 3 parallel agents for scorecard |
sprint | code-reviewer, security-auditor at phase gates | Automatic at BUILD→REVIEW, REVIEW→SHIP |
security-audit | security-auditor + secret-scanner tool | Agent reasoning + automated scanning |
rescue | incident-responder | Single agent for diagnosis |
party-mode | Any combination of agents | 2-4 agents per round, parallel spawn |
subagent-driven-development | implementer + spec-reviewer + quality-reviewer | Per-task cycle with two-stage review |
writing-plans | plan-document-reviewer | Single agent after plan written (skipped for Simple plans) |
