brunob54
UserClaude Code plugin that runs a development pipeline autonomously: spec → plan → plan-review rounds → batched subagent implementation → code-review rounds, stopping only on errors. Fork of obra/superpowers.
Categories
Indexed Skills (28)
handoff
Write a continuation prompt for a fresh session into tmp/docs/<date>-handoff-<slug>.md, save state, and print the prompt so the user can clear the context window and continue the work elsewhere.
pickup
Resume work in a fresh session from the newest handoff file written by /handoff, from a named handoff file, or from an unfinished orchestration run found on a local feature branch. Checks first whether commits made after the handoff already did its task.
brainstorming
MUST USE when the user wants new features, behavior changes, refactoring with new capabilities, or architecture decisions and no approved design exists yet. Produces an approved design document before any code is written. Triggers on: "build this", "add a feature", "I want to change", "how should we", "design", "architect", "new project", "refactor", "we need to add/build/create", "implement a new". Routed by using-superpowers, or invoke directly via /brainstorming.
claude-md-creator
Creates minimal, high-signal CLAUDE.md and AGENTS.md context files based on empirical best practices. Invoke on /init command, "create CLAUDE.md", "update CLAUDE.md", "write AGENTS.md", or "set up Claude Code for this project". Also invoked by brainstorming when repo lacks a context file. tools: Read, Glob, Grep, Bash, Edit
deliberation
Use BEFORE brainstorming when facing a complex architectural, technology, or design decision where the options are not yet well-defined or the problem itself may need reframing. Assembles named stakeholder perspectives that each speak once without debate, then surfaces where they converge and where real tension remains — without forcing a premature choice. Triggers on: "should we use X or Y", "not sure which approach", "evaluate these options", "what are the trade-offs between", "help me think through this decision", "architecture decision", "technology choice". Routed by using-superpowers before brainstorming when the decision space is unclear.
dispatching-parallel-agents
Use when 2+ tasks are independent and can run concurrently without file or state conflicts or sequential dependencies. Triggers on: "run these in parallel", "do these at the same time", plans with independent tasks, when subagent-driven-development identifies parallelizable work.
error-recovery
Maintains a project-specific known-issues.md mapping recurring errors to their solutions. Consulted automatically by systematic-debugging before investigation. Saves time by avoiding rediscovery of known problems across sessions. Triggers on: "save this fix", "remember this error", "known issues", or automatically when systematic-debugging resolves a recurring error.
executing-plans
MUST USE when a plan.md exists and implementation needs to begin. Executes in controlled batches with verification checkpoints. Triggers on: "execute the plan", "start building", "follow the plan", "go". Routed by using-superpowers or writing-plans handoff.
frontend-design
MUST USE for any frontend, UI, or web interface implementation. Enforces production-grade visual quality, accessibility, responsive design, and professional polish. Triggers on: "build a UI", "frontend", "website", "landing page", "dashboard", "make it look professional", any React/Vue/Svelte/HTML component work. Routed by using-superpowers, or invoke directly via /frontend-design.
multi-code-review
MUST USE when a branch needs N independent whole-branch code review rounds with fixes applied between rounds. M clean-context reviewer subagents per round (default 1) under a rotating lens (correctness/spec alignment, adversarial red-team, security, test quality); one fix subagent per round for Critical/Important findings; sidecar audit log; early exit after two consecutive clean rounds. Invoked by subagent-driven-development at the final whole-branch review gate, or directly via /multi-code-review [BASE] [N|N=<n>] [M=<m>]. Triggers on: "multi code review", "independent code reviews", "several code reviews", "review the branch N times", "code review rounds", "whole-branch review loop".
multi-doc-review
MUST USE when a spec or plan document needs N independent review rounds with findings merged between rounds. M clean-context reviewer subagents per round (default 1) under a rotating lens; findings triaged into the document; a sidecar audit log records every disposition; early exit after two consecutive clean rounds. Invoked by brainstorming (spec gate) and writing-plans (plan gate), or directly via /multi-doc-review <doc-path> [N|N=<n>] [M=<m>]. Triggers on: "multi doc review", "document review rounds", "review rounds", "independent reviews", "review the spec again", "review this N times".
orchestrating-development
MUST USE when the user asks to orchestrate the full development pipeline from an approved spec: plan writing, N plan-review rounds, batched implementation, and N code-review rounds run autonomously, stopping only on major errors, ending before merge/PR. Triggers on: "orchestrate the development", "orchestrate docs/superpowers-orchestrator/<date>-<slug>/specs/...", "run the whole pipeline autonomously", "resume orchestration", "abandon orchestration". Requires the Agent tool with nested dispatch (Claude Code only).
performance-investigation
MUST USE when investigating or fixing performance issues: slow responses, high memory usage, CPU spikes, throughput degradation, or optimization requests. Enforces measure-first methodology — profile before guessing, baseline before fixing, re-measure after every change. Distinct from systematic-debugging (which changes behavior to fix bugs) and brainstorming (which designs new features). Triggers on: "slow", "performance", "optimize", "speed up", "latency", "throughput", "memory leak", "high CPU", "profiling", "benchmark", "bottleneck", "takes too long", "response time", "why is this slow", "make it faster", "reduce memory", "loading time". Routed by using-superpowers, or invoke directly via /performance-investigation.
premise-check
Validates whether proposed or in-progress work should exist before investing in it. Invoke BEFORE designing, planning, or building anything non-trivial — and WHEN new evidence arrives that could change the motivation for existing work. Triggers on: 'design a system', 'create a plan', 'build out the full version', 'extend this to handle', architecture proposals, or any moment where test results, research findings, or changed requirements weaken the original reason for doing something. Also triggers when you catch yourself updating a document's facts without reassessing its conclusions.
refactoring
MUST USE when restructuring existing code without changing behavior: extracting functions/modules, inlining, simplifying, decoupling, reorganizing files, renaming across the codebase, or cleaning up code structure. Enforces behavior-locking tests before any structural change and incremental verification after each move. Distinct from brainstorming (which designs new behavior) and bug fixing (which changes behavior). Triggers on: "refactor", "restructure", "reorganize", "clean up this code", "extract into", "inline this", "simplify", "decouple", "modularize", "move these files", "split this module", "consolidate", "reduce complexity". Routed by using-superpowers, or invoke directly via /refactoring.
requesting-code-review
Structured code review against requirements, quality, and security standards. Invoke after meaningful code changes or before merge. Triggers on: "review my code", "code review", "check this before merge", "security review", "is this secure", "look over my changes", "second pair of eyes", "check the diff". Routed by using-superpowers or executing-plans after implementation.
researching-prior-art
Grounds one technology decision in verified external evidence before design approaches are compared. Dispatches a controller subagent that runs N read-only researcher subagents in parallel (candidate source reading, version verification anchored to this repository's manifest, registry existence and health, prior art) and merges their file-based reports into one evidence report. Invoked by brainstorming at its research gate with the decision, candidate list, N, topic slug, and project directory; or directly via /researching-prior-art. Triggers on: "research prior art", "prior-art research", "research the candidates", "verify the library", "research this dependency".
self-consistency-reasoner
Internal reasoning technique invoked by systematic-debugging and verification-before-completion for high-stakes multi-step inference. Generates N independent reasoning paths and takes majority vote to surface confident-but-wrong single-chain failures. DO NOT invoke independently — this skill is embedded in the skills that need it.
subagent-driven-development
Executes plans using parallel subagents with per-task implementation and staged review gates. Invoke for parallel plan execution in the current session. Also provides Batched Autonomous Mode: implement up to N tasks per session with a fixed task-cap batch boundary, write a handoff into state.md, and resume after /clear. Triggers on: "implement the next N tasks", "execute the plan in batches", "resume the plan". Routed by writing-plans handoff or using-superpowers for large plans with independent tasks.
systematic-debugging
Invoke BEFORE attempting any fix when a bug, test failure, error, warning, unexpected behavior, or performance regression appears. Enforces hypothesis-driven root cause analysis — no fix without evidence. Triggers on: error messages, stack traces, "it's broken", "not working", "bug", test failures, blank/white screens, "works locally but not in production", performance degradation, console warnings, "can't figure out why". Also routed by using-superpowers for debugging tasks.
test-driven-development
MUST USE for any behavior change: write failing tests before production code. No exceptions. Triggers on: "TDD", "write tests first", any implementation task, bug fix needing regression tests, behavior changes during execution. Routed by using-superpowers, or invoke directly via /test-driven-development.
token-efficiency
Always-on operational standard. Enforces concise responses, parallel tool execution, no redundant work, exploration tracking, and proactive context compression throughout every session. Applied automatically at session start.
using-git-worktrees
Use before implementation when work should be isolated from the current branch. Triggers on: "use a worktree", "isolate this work", "don't touch main", experimental or risky changes that need isolation.
using-superpowers
BLOCKING REQUIREMENT — invoke this skill BEFORE writing any code, editing files, debugging, planning, reviewing, or making any technical tool calls beyond reading files. This is the mandatory workflow router for ALL technical tasks. Matches: "implement", "build", "fix", "debug", "refactor", "optimize", "add feature", "change", "update", "create", "develop", "plan", "review", "test", or ANY request that involves code changes. Do NOT skip this skill even if the task seems simple. Invoke FIRST, then follow its routing.
verification-before-completion
Invoke BEFORE saying "done", "tests pass", "ready to merge", or any completion claim. Requires fresh command output as evidence — no completion without proof. Also routed by using-superpowers at task end.
writing-plans
MUST USE after design approval to decompose requirements into executable task plans with verification commands and TDD ordering. Triggers on: "write a plan", "break this down", "plan the implementation", after brainstorming approval. Routed by brainstorming as the next step.
finishing-a-development-branch
MUST USE when implementation is verified and you need to choose the branch outcome: merge, PR, keep, or discard. Triggers on: "merge this", "create a PR", "squash and merge", "we're done with this branch", "clean up the branch", "push this", "get it merged", after verification-before-completion passes. Routed by using-superpowers or executing-plans at completion.
receiving-code-review
Handles review feedback with technical rigor: verify suggestions, resolve unclear items, implement fixes in priority order. Invoke when review comments are received or user says "address review feedback". Routed by using-superpowers when review feedback arrives.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.