SkillHub

superpowers

v1.0.0

Spec-first, TDD, subagent-driven software development workflow. Use when: (1) building any new feature or app — triggers brainstorm → plan → subagent execution loop, (2) debugging a bug or test failure — triggers systematic root-cause process, (3) user says "let's build", "help me plan", "I want to...

Sourced from ClawHub, Authored by wlshlad85

Installation

Please help me install the skill `superpowers` from SkillHub official store. npx skills add wlshlad85/superpowers

Superpowers — OpenClaw Edition

Adapted from obra/superpowers. Mandatory workflow — not suggestions.

The Pipeline

Idea → Brainstorm → Plan → Subagent-Driven Build (TDD) → Code Review → Finish Branch

Every coding task follows this pipeline. "Too simple to need a design" is always wrong.


Phase 1: Brainstorming

Trigger: User wants to build something. Activate before touching any code.

See: references/brainstorming.md

Summary: 1. Explore project context (files, docs, recent commits) 2. Ask clarifying questions — one at a time, prefer multiple choice 3. Propose 2–3 approaches with trade-offs + recommendation 4. Present design in sections, get approval after each 5. Write design doc → docs/plans/YYYY-MM-DD-<topic>-design.md → commit 6. Hand off to Phase 2: Writing Plans

HARD GATE: Do NOT write any code until user approves design.


Phase 2: Writing Plans

Trigger: Design approved. Activated by brainstorming phase.

See: references/writing-plans.md

Summary: - Write a detailed task-by-task implementation plan - Each task = 2–5 minutes: write test → watch fail → implement → watch pass → commit - Save to docs/plans/YYYY-MM-DD-<feature>.md - Announce: "I'm using the writing-plans skill to create the implementation plan." - After saving, offer two execution modes: - Subagent-driven (current session): sessions_spawn per task + two-stage review - Manual execution: User runs tasks themselves


Phase 3: Subagent-Driven Development

Trigger: Plan exists, user chooses subagent-driven execution.

See: references/subagent-development.md

Per-task loop (OpenClaw): 1. sessions_spawn an implementer subagent with task + full plan context 2. Wait for completion announcement 3. sessions_spawn a spec-reviewer subagent → must confirm code matches spec 4. sessions_spawn a code-quality reviewer subagent → must approve quality 5. Fix any issues, re-review if needed 6. Mark task done, move to next 7. Final: dispatch overall code reviewer → hand off to Phase 5

TDD is mandatory in every task. See references/tdd.md.


Phase 4: Systematic Debugging

Trigger: Bug, test failure, unexpected behaviour — any technical issue.

See: references/systematic-debugging.md

HARD GATE: No fixes without root cause investigation first.

Four phases: 1. Root Cause Investigation (read errors, reproduce, check recent changes, trace data flow) 2. Pattern Analysis (find working examples, compare, identify differences) 3. Hypothesis + Testing (one hypothesis at a time, test to prove/disprove) 4. Fix + Verification (fix at root, not symptom; verify fix doesn't break anything)


Phase 5: Finishing a Branch

Trigger: All tasks complete, all tests pass.

See: references/finishing-branch.md

Summary: 1. Verify all tests pass 2. Determine base branch 3. Present 4 options: merge locally / push + PR / keep / discard 4. Execute choice 5. Clean up


OpenClaw Subagent Dispatch Pattern

When dispatching implementer or reviewer subagents, use sessions_spawn:

Goal: [one sentence]
Context: [why it matters, which plan file]
Files: [exact paths]
Constraints: [what NOT to do — no scope creep, TDD only]
Verify: [how to confirm success — tests pass, specific command]
Task text: [paste full task from plan]

Run sessions_spawn with the task as a detailed prompt. The sub-agent announces results automatically.


Key Principles

  • One question at a time during brainstorm
  • TDD always — write failing test first, delete code written before tests
  • YAGNI — remove unnecessary features from all designs
  • DRY — no duplication
  • Systematic over ad-hoc — follow the process especially under time pressure
  • Evidence over claims — verify before declaring success
  • Frequent commits — after each green test