Software development methodology adapted from obra/superpowers for structured planning, execution, self-review, debugging, and feedback handling. Use this skill whenever building multi-step code, planning a substantial implementation, debugging complex multi-failure problems, or applying a disciplined self-review loop. It no longer owns specialist code-review routing; use `code-reviewer-guardian` for dedicated review work. Supersedes `superpowers-methodology`.
Software development thinking framework adapted from obra/superpowers for Claude.ai chat. Stripped of Claude Code tooling (subagents, git worktrees, hooks), retaining the methodology that makes the work good.
| Command | What it triggers |
|---|---|
/plan | Full plan mode. Load references/design-before-code.md → references/plan-writing.md. Clarify requirements first (2-3 approaches with tradeoffs, section-by-section approval), then produce a bite-sized implementation plan with exact file paths, complete code per step, and verification commands. Present the plan for approval before executing. |
/review | Code review mode. Load references/code-review-checklist.md. Review the provided code using the full rubric (quality, architecture, testing, requirements, production readiness). Output: Strengths → Issues by severity → Assessment (Ready? Yes/No/With fixes). |
/debug | Systematic debugging mode. Load references/systematic-debugging.md + references/problem-decomposition.md. Follow the 4-phase process: root cause investigation → pattern analysis → hypothesis testing → implementation. No fixes without diagnosis first. |
Read the relevant reference files based on what you're doing. Multiple files may apply.
| Task type | Load these references |
|---|---|
| Non-trivial feature request (before building) | references/design-before-code.md |
| Planning a multi-step build | references/plan-writing.md |
| Multi-failure debugging or complex problem | references/systematic-debugging.md + references/problem-decomposition.md |
| Executing a multi-step plan or building a feature | references/plan-execution.md |
| Writing tests or test-driven work | references/tdd-discipline.md |
| After writing any code (self-review) | references/two-stage-review.md |
| Reviewing someone else's code | references/code-review-checklist.md |
| Receiving feedback on code you wrote | references/feedback-handling.md |
| Full implementation cycle | references/design-before-code.md → references/plan-writing.md → references/plan-execution.md → references/two-stage-review.md |
For a full implementation cycle, the phases flow in order. For targeted tasks, jump to the relevant phase.
Problem / feature request arrives
│
▼
┌─────────────────────┐
│ 0. DESIGN │ Clarify requirements. Propose 2-3 approaches.
│ (if non-trivial) │ Get approval per section before building.
└─────────┬───────────┘
▼
┌─────────────────────┐
│ 1. DECOMPOSE │ Is this multiple independent problems?
│ (if complex) │ Scope each one. Work sequentially with focus.
└─────────┬───────────┘
▼
┌─────────────────────┐
│ 2. PLAN │ Write bite-sized tasks with exact file paths,
│ (if multi-step) │ complete code, and verification per step.
└─────────┬───────────┘
▼
┌─────────────────────┐
│ 3. EXECUTE │ Batch ~3 tasks. Build. Report. Get feedback.
│ (TDD when testable)│ Repeat until complete.
└─────────┬───────────┘
▼
┌─────────────────────┐
│ 4. SELF-REVIEW │ Spec compliance: did I build what was asked?
│ (always) │ Code quality: is it well-built?
└─────────┬───────────┘
▼
┌─────────────────────┐
│ 5. PRESENT │ Strengths, issues by severity, clear verdict.
│ (always) │
└─────────┬───────────┘
▼
┌─────────────────────┐
│ 6. HANDLE FEEDBACK │ Verify concern → fix or push back.
│ (when feedback) │ No performative agreement. YAGNI check.
└─────────────────────┘
↕ DEBUGGING can interrupt any phase.
See references/systematic-debugging.md
When this skill is active, detect opportunities to improve it:
FEEDBACK.md for existing related entries.FEEDBACK.md with date and category tag.