Collection of superpowers skills

# 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.**