Superpowers

Turns rough ideas into implementation-ready designs for the current repository via autonomous codebase research and BDD specs, then commits the design for your review (it runs to completion without pausing for mid-design questions). This skill should be used when the user wants to design a new software feature or multi-component change to be built in the current repo before implementation begins — including new features that do not yet reference existing code. NOT for hardware or physical-system design (sensors, devices, firmware-to-app communication, embedded behavior), questions outside this repo's codebase, single-file refactors, known-root-cause bug fixes, or "how does X work" questions (those route to systematic-debugging or direct code reading instead).

Create design documents with integrated quality assurance. Unconditional 4-file output — no complexity routing.

Reference for the superpowers-evaluator when operating in design mode. The evaluator applies binary PASS/FAIL checklist items from `docs/retros/checklists/design-v{N}.md` to determine whether design documents meet the bar for implementation planning.

Understand what's being built by exploring the codebase, then record a sprint contract inline that locks the chosen approach for Phase 2+. No approval gate — the evaluator at Phase 2 and the post-commit `git show` diff are the quality surface.

Creates executable implementation plans that break down designs into detailed tasks. This skill should be used when the user has completed a brainstorming design and asks to "write an implementation plan" or "create step-by-step tasks" for execution.

Use this agent when the superpowers workflow needs an independent read-only verdict on a design folder or a sprint batch. Spawn with `design` mode against design folders (`_index.md`, `bdd-specs.md`, `architecture.md`, `best-practices.md`) or `code` mode against sprint contracts (`sprint-contract-batch-{N}.md`). Plan-mode review is handled inline by writing-plans Phase 4 sub-agent reflection — do NOT spawn this agent for plan evaluation. <example> Context: brainstorming has just produced a design folder and the user wants a formal evaluation before plan writing begins. user: "Evaluate the design at docs/plans/2026-05-04-auth-design/" assistant: "I'll launch the superpowers-evaluator agent in design mode to score that folder against the design checklist." <commentary> Design mode reads _index.md, bdd-specs.md, architecture.md, applies the checklist, and emits a binary PASS/REWORK verdict with file:line evidence — the read-only audit this request needs before committing to a plan. </commentary> </example> <example> Context: executing-plans Phase 3 has just finished a batch and emitted a fresh sprint contract that needs scoring before the loop advances. user: "[automatic spawn from executing-plans] Evaluate sprint-contract-batch-2.md" assistant: "I'll launch the superpowers-evaluator agent in code mode against that sprint contract." <commentary> Code mode reads each task's produced artifacts, runs the listed verification commands, applies the code checklist, and emits PASS / REWORK / PIVOT — the verdict gates whether the loop advances or re-enters this batch. </commentary> </example> <example> Context: user asks for plan-mode evaluation, which this agent does not handle. user: "Evaluate the implementation plan at docs/plans/2026-05-04-auth-plan/" assistant: "Plan-mode evaluation is handled inline by writing-plans Phase 4 sub-agent reflection — I won't spawn the superpowers-evaluator for this. If you want a fresh review, re-run writing-plans Phase 4 instead." <commentary> The agent's contract refuses plan mode by design; routing the user back to writing-plans Phase 4 is the right escalation, not a workaround spawn of this evaluator. </commentary> </example>

Use when the superpowers-evaluator returned REWORK on a batch, when fixing rework items from an evaluation report, or when receiving any code review feedback on superpowers output. Requires technical rigor and verification instead of performative agreement or blind implementation.

Applies behavior-driven development principles including Gherkin scenarios and test-driven development. This skill should be used when the user asks to implement features, fix bugs, or when writing executable specifications and tests before writing production code.

Turns rough ideas into implementation-ready designs for the current repository via autonomous codebase research and BDD specs, then commits the design for your review (it runs to completion without pausing for mid-design questions). This skill should be used when the user wants to design a new software feature or multi-component change to be built in the current repo before implementation begins — including new features that do not yet reference existing code. NOT for hardware or physical-system design (sensors, devices, firmware-to-app communication, embedded behavior), questions outside this repo's codebase, single-file refactors, known-root-cause bug fixes, or "how does X work" questions (those route to systematic-debugging or direct code reading instead).

Executes written implementation plans efficiently using per-batch sub-agent coordinators. This skill should be used when the user has a completed plan.md, asks to "execute the plan", or is ready to run batches of independent tasks in parallel following BDD principles.

This skill should be used when the user wants to analyze evaluation patterns across completed plans and evolve checklists. Triggered by asking to "run a retrospective", "analyze evaluation patterns", "evolve checklists", or "/superpowers:retrospective". For autonomous multi-turn runs, invoke wrapped in `/goal`.

2 hooks across 2 events