Dude Superpowers has to be on here and not for just the build portion. But its systematic debugging skill is impressive
Open the batch installer for this collection and generate commands only when you need them.
by obra
requesting-code-review is a lightweight workflow for dispatching the superpowers:code-reviewer subagent with a clean git diff, requirements, and change summary so reviews happen at the right time and produce actionable, severity-ranked feedback before merge.
by obra
subagent-driven-development is a skill for executing implementation plans with a fresh subagent per task, then reviewing each result in two passes: spec compliance first, code quality second. It includes prompt templates for the implementer, spec reviewer, and code quality reviewer.
by obra
systematic-debugging is a root-cause-first debugging skill for bugs, flaky tests, build failures, and unexpected behavior. Learn the four-phase workflow, companion files, and when to use it before proposing fixes.
by obra
Install and use the test-driven-development skill to enforce strict TDD: write a failing test first, verify the failure, implement the minimum code, then refactor safely.
by obra
using-git-worktrees helps create isolated Git worktrees for new branch work with directory selection, ignore checks, and safer parallel workflows without touching your current checkout.
by obra
using-superpowers is a session-start skill from obra/superpowers that forces skill lookup before any reply, helping agents discover and activate the right workflow first.
by obra
verification-before-completion is a final-check skill that blocks unsupported completion claims. Learn when to use it, how to install it from obra/superpowers, and how to match each status claim to fresh verification evidence.
by obra
writing-plans helps turn a spec or requirements doc into a detailed implementation plan with file-level guidance, task sequencing, testing steps, and a review prompt before coding starts.
by obra
writing-skills is a Skill Authoring guide for creating, editing, and validating agent skills with a test-driven workflow. Learn the key files, prerequisites, and practical steps for pressure scenarios, baseline tests, and concise SKILL.md iteration.
by obra
brainstorming is a pre-implementation skill that explores context, asks clarifying questions one at a time, and requires design approval before any code. Includes an optional visual companion and strong support for Requirements Planning.
by obra
dispatching-parallel-agents is an Agent Orchestration skill for splitting truly independent tasks across separate agents with isolated context and coordinated results.
by obra
executing-plans helps agents follow a written implementation plan: review it first, execute tasks in order, run specified checks, stop on blockers, and hand off to a finishing workflow. Best for Project Management and other plan-led delivery.
by obra
The finishing-a-development-branch skill helps close a Git branch safely after implementation is done. It verifies tests, checks the base branch, then presents four clear options: merge locally, push for a Pull Request, keep the branch, or discard the work.
by obra
receiving-code-review helps you verify PR feedback before editing code. Use it to restate review comments, check them against the codebase, ask for clarification on unclear items, and push back when suggestions do not fit.
# How to Use Superpowers Skills Effectively Do not treat a task as “read the request and start coding.” Superpowers changes the default workflow: **check for relevant skills first, then let the skills determine how to work**. ## Core Rule Before responding, exploring files, asking clarifying questions, or implementing anything, first check whether a Superpowers skill applies. If a skill is relevant, use it first. User instructions define **what** to do. Skills define **how** to do it. --- ## Recommended Workflow ### 1. Start with `using-superpowers` Use this first for almost every task. Its job is to decide whether another skill should control the workflow. --- ### 2. Use `brainstorming` for new work or behavior changes Use it before: - building a feature - adding functionality - changing behavior - doing meaningful implementation work What to do: - understand the current context - ask clarifying questions one at a time - propose a few approaches with trade-offs - recommend one - get approval - write the design spec Do **not** code during brainstorming. --- ### 3. After approval, use `writing-plans` Turn the approved design into a concrete execution plan. The plan should include: - files to create or modify - small implementation steps - testing and verification steps A good plan should be clear enough for another agent to execute. --- ### 4. Use `using-git-worktrees` before implementation Prefer an isolated worktree instead of modifying the main workspace directly. This keeps feature work cleaner and safer. --- ### 5. Prefer `subagent-driven-development` for execution If subagents are available, use them to execute plan tasks one by one. Recommended pattern: - assign one focused task to one subagent - review for spec alignment - review for code quality - fix issues - mark the task complete --- ### 6. Use `executing-plans` if subagents are not available If you already have a written plan but are not using subagents, use `executing-plans`. Rules: - read the plan first - review it before starting - execute one task at a time - verify as you go - do not guess when blocked --- ## Supporting Skills ### `test-driven-development` Use when test-first implementation is appropriate: 1. write a failing test 2. confirm it fails 3. implement the minimum fix 4. run tests again --- ### `systematic-debugging` Use for bug fixing. Do not guess. Reproduce, narrow the problem, test hypotheses, find the root cause, then verify the fix. --- ### `requesting-code-review` / `receiving-code-review` Use review as a formal step, not an afterthought. --- ### `verification-before-completion` Before declaring work done, verify that: - tests pass - required commands succeed - the implementation matches the design and plan --- ### `finishing-a-development-branch` After implementation is complete: 1. verify tests 2. identify the base branch 3. present the completion options 4. clean up appropriately --- ## End-to-End Flow `using-superpowers` → `brainstorming` → `writing-plans` → `using-git-worktrees` → `subagent-driven-development` or `executing-plans` → supporting skills as needed → `verification-before-completion` → `finishing-a-development-branch` --- ## Operating Principle **User instructions define the goal. Skills define the method. Design before implementation. Plan before execution. Verify before completion.**
