Superpowers: From Idea to Plan
James has been using Claude Code for weeks. He can write skills, install plugins, run hooks, and even set up autonomous Ralph Loops. But every time he starts a new project, the same pattern repeats: he jumps straight into building, realizes halfway through that he missed a requirement, backtracks, rewrites three files, and ends up with a tangled mess that barely works. The output is functional. The process is chaos.
Emma watches him restart a skill for the third time in one afternoon. "You know how to use every tool Claude offers," she says. "But you're launching a project without a kickoff meeting. No scope, no requirements, no success criteria. You just start building and hope it works out."
"I've tried planning," James says. "I spend 20 minutes writing a doc that's outdated before I finish the first draft."
"That's because you planned alone," Emma says. "What if Claude asked the right questions, challenged your assumptions, and turned your answers into a plan so detailed that building becomes mechanical?"
You are doing exactly what James is doing. You have the tools. What you need is a workflow that prevents the expensive mistake: not a bad skill, but building the wrong thing entirely.
Installing Superpowers
Before anything else, a prediction: what happens when you install a plugin that adds over a dozen skills at once? Does it slow Claude down? Do all skills activate simultaneously? Does Claude get confused about which skill to use?
Install the plugin and find out.
Step 1: Install from the Official Marketplace
claude
/plugin install superpowers@claude-plugins-official
Step 2: Reload Plugins
After installation, reload so Claude recognizes the new skills:
/reload-plugins
You should see output confirming the reload, showing updated counts for plugins, skills, agents, and hooks.
Step 3: Verify Installation
List your available skills:
/skills
Scroll through the list. You will see skills prefixed with superpowers:, including superpowers:brainstorming, superpowers:writing-plans, superpowers:executing-plans, superpowers:test-driven-development, and others.
What you observed: Installing a multi-skill plugin does not slow Claude down. Skills load on-demand when invoked, not all at once. Claude uses the skill descriptions to determine which skill fits the current task. You do not need to memorize which skill to call; Claude matches your intent to the right skill automatically in most cases. You can also invoke any skill explicitly with the superpowers: prefix.
Where the files live: Unlike project-level skills (which go in .claude/skills/), plugins install into ~/.claude/plugins/cache/. No files appear in your project repository. This is the same pattern you learned in Lesson 16: plugins are user-level, not project-level.
The Seven-Step Workflow
Superpowers is not a random collection of skills. It implements a complete development workflow, built by Jesse Vincent and the Prime Radiant team, that enforces a specific sequence: think before you build.
Here is the full workflow:
| Step | Skill | What It Does | What It Prevents |
|---|---|---|---|
| 1 | brainstorming | Refines rough ideas through Socratic questioning | Building the wrong thing |
| 2 | using-git-worktrees | Creates isolated branch with clean test baseline | Polluting main branch with experimental code |
| 3 | writing-plans | Breaks design into 2-5 minute tasks with file paths | Scope ambiguity and forgotten requirements |
| 4 | executing-plans / subagent-driven-development | Executes tasks with verification at each step | Unverified implementation that drifts from plan |
| 5 | test-driven-development | Enforces red-green-refactor cycle | Untested code that breaks later |
| 6 | requesting-code-review | Reviews implementation against the original plan | Merged code that doesn't match the design |
| 7 | finishing-a-development-branch | Verifies tests, presents merge options, cleans up | Abandoned branches and forgotten cleanup |
The philosophy: the most expensive mistake in software development is not a bug. Bugs are cheap to fix. The expensive mistake is building the wrong thing entirely, discovering it three weeks later, and throwing away the work. Steps 1-3 exist to prevent that. Steps 4-7 ensure what you build matches what you planned.
This lesson covers Steps 1 and 3 (brainstorming and writing-plans). The next lesson covers Steps 4-7: what happens when Claude executes the plan.
Brainstorming: Socratic Design Refinement
The brainstorming skill does not ask you to write a design document. Instead, it interviews you. One question at a time, often with multiple-choice options, building the design incrementally from your answers.
Starting a Brainstorm
Open Claude Code in a project directory and describe what you want to build:
I want to build a Claude Code skill that reviews my writing
for clarity and suggests improvements. It should work on any
Markdown file I point it at.
Claude activates the brainstorming skill. Instead of immediately generating a SKILL.md file, it starts asking questions:
Claude's first question (example):
"What kind of writing will this skill review?
- Technical documentation (README files, API docs)
- Business writing (emails, reports, proposals)
- Educational content (lessons, tutorials)
- All of the above (general-purpose clarity reviewer)"
You pick option 4. Claude stores your answer and asks the next question:
"How should the skill deliver its feedback?
- Inline suggestions (rewrite unclear sentences directly)
- A summary report listing issues with line references
- A conversation where it asks you about unclear passages
- Something else (describe your approach)"
This continues through design decisions: what tools should the skill have access to, how should it handle different writing styles, what counts as "unclear," and where to draw the line between helpful and nitpicky. Each question builds on your previous answers. After several rounds, Claude presents the accumulated design document, section by section, for your review.
What the Output Looks Like
The brainstorming skill saves the final design to docs/plans/ in your project:
docs/plans/
writing-clarity-skill-design.md
This file contains the design decisions you made, the alternatives you rejected, and the scope you defined. It becomes the input for the next step: writing-plans.
The Power of Disagreement
Here is what makes brainstorming a collaboration, not a dictation.
Claude's recommendation:
"For detecting unclear writing, I recommend checking sentence length and passive voice. These are reliable clarity signals."
Your pushback:
"I disagree. Short sentences aren't always clearer, and passive voice is sometimes the right choice (especially in scientific writing). I want the skill to focus on whether the reader can understand the main point of each paragraph on first reading."
Claude's adaptation:
"Good point. Readability metrics like sentence length are proxies, not goals. I'll redesign around a 'main point test': for each paragraph, the skill identifies what it thinks the main point is and flags paragraphs where the point is buried or ambiguous. It will still note long sentences, but as suggestions rather than errors."
Claude suggested a mechanical approach. You pushed back with a reason grounded in your experience. Claude adapted and proposed a design that neither of you started with. The brainstorming skill is not a questionnaire; it makes recommendations, accepts pushback, and converges through dialogue.
Writing Plans: From Design to Tasks
You have a design document. Now what?
The writing-plans skill takes your brainstorming output and breaks it into granular implementation tasks: 2-5 minutes each, with exact file paths, complete code descriptions, and verification steps.
Invoking Writing Plans
After brainstorming completes (or with any existing design document), ask Claude to create an implementation plan:
Create an implementation plan for the writing clarity skill
design in docs/plans/writing-clarity-skill-design.md
Claude activates the writing-plans skill and produces a structured plan.
What a Plan Looks Like
Here is a simplified example of what writing-plans produces:
## Task 1: Create skill directory (2 min)
**Files:** .claude/skills/writing-clarity/SKILL.md
**Action:** Create the skill directory and an empty SKILL.md
with YAML frontmatter (name, description, allowed-tools)
**Verify:** File exists, YAML frontmatter parses without errors
## Task 2: Write the skill persona and instructions (3 min)
**Files:** .claude/skills/writing-clarity/SKILL.md
**Action:** Add persona ("You are a writing clarity coach"),
core instructions (main-point test per paragraph, flag buried
points, suggest rewrites), and output format (summary with
line references)
**Verify:** Invoke skill on a sample paragraph, confirm it
produces feedback in the expected format
## Task 3: Add edge case handling (3 min)
**Files:** .claude/skills/writing-clarity/SKILL.md
**Action:** Add instructions for bullet lists (skip main-point
test), code blocks (skip entirely), and short paragraphs under
two sentences (flag only if genuinely unclear)
**Verify:** Run skill on a file with mixed content types,
confirm it handles each correctly
## Task 4: Package as plugin (3 min)
**Files:** plugin.json, .claude/skills/writing-clarity/SKILL.md
**Action:** Create plugin.json manifest with name, version,
description, and skill reference. Test installation with
/plugin install from local path.
**Verify:** Plugin installs, skill appears in /skills list
Each task has three elements: what files to touch, what to do, and how to verify it worked. The verification step is critical. Without it, tasks drift from the design, errors compound, and you discover problems late.
Comparing Plan Granularity to Your Habits
Think about how you naturally break down work. Most people create tasks like "build the skill" or "set up the plugin." Those tasks take 30-60 minutes and hide dozens of decisions inside them.
Writing-plans produces tasks that take 2-5 minutes because:
- Each task has one decision. "Create the dataclass" is one decision. "Implement parsing, scanning, and reporting" is twelve decisions hiding in one task.
- Verification is immediate. You know within 2 minutes whether the task succeeded. No waiting until the end to discover something broke.
- Handoff is possible. The tasks are detailed enough that a different developer (or a different Claude session) could pick up any task independently. This is what makes subagent-driven-development possible in Step 4.
Hands-On: Your First Brainstorm-to-Plan Cycle
Step 1: Choose a Small Feature
Pick something from your own work. Good candidates:
| Domain | Example Feature |
|---|---|
| Writing | "A skill that proofreads my emails before sending" |
| Organization | "A skill that summarizes long documents into key points" |
| Learning | "A skill that quizzes me on material I'm studying" |
| Productivity | "A skill that helps me plan my week based on my task list" |
Keep it small: something you could build in an hour or two. The goal is experiencing the workflow, not finishing a large project.
Step 2: Run Brainstorming
Open Claude Code and describe your feature. Let the brainstorming skill guide you through the design:
I want to build [YOUR FEATURE DESCRIPTION].
Help me think through the design.
As the questions come, pay attention to two things:
- Questions you hadn't considered. The brainstorming skill often asks about edge cases, error handling, or configuration that you would have discovered mid-implementation.
- Recommendations you disagree with. Push back at least once. Watch how the design adapts.
Step 3: Generate the Plan
After brainstorming completes, invoke writing-plans:
Create an implementation plan from the design we just completed.
Review the task list. Compare the granularity to how you would have broken the work down yourself. Are the tasks smaller than yours? More specific? Do the verification steps catch things you would have skipped?
Why This Matters
James stares at his plan. Twelve tasks, each with exact file paths and verification steps. "This is what I've been missing," he says. "I always knew what to build, but I never planned the right order to build it in. And I never wrote down how to verify each piece."
Emma nods. "How long did brainstorming take?"
"Maybe five minutes of answering questions. And it asked about error handling for empty directories, which I definitely would have forgotten until a user hit that bug."
"That five minutes saved you the three-hour rewrite you did last Tuesday." Emma pauses. "I used to skip planning too. I thought it was wasted time. Then I lost three weeks on a project because I built an entire onboarding workflow before realizing the client wanted self-service signup, not invite-only. The work was solid. And all of it went in the trash because I never asked the right questions at the start."
James looks at the plan again. "So the brainstorming skill is basically forcing me to ask those questions."
"And writing-plans turns your answers into steps small enough that you'll catch a wrong assumption in 5 minutes instead of 5 days." She points at the screen. "You have a plan. But a plan is just words on a page. In the next lesson, you'll see what happens when Claude executes it: tests first, code review, branch management, and the full lifecycle from plan to merged code."
Try With AI
Install and brainstorm:
Install superpowers and brainstorm a Claude Code skill that does
something useful for your daily work. Notice how many questions the
brainstorming skill asks before proposing any design details.
What you're learning: Design-first thinking. The brainstorming skill forces you to make decisions about scope, edge cases, and design before building anything. Count the questions: most people skip at least half of them when planning alone.
Compare plan granularity:
After brainstorming, run writing-plans on the design document.
Compare the plan's task size (2-5 minutes each) to how you would
naturally break down the same work. What decisions does the plan
make explicit that you would have left implicit?
What you're learning: Task decomposition at a level of detail that makes verification possible after every step, not just at the end. The gap between your natural granularity and the plan's granularity reveals hidden complexity you typically absorb without noticing.
Test the collaboration:
Start a brainstorm for any feature. When the brainstorming skill
makes its first recommendation, deliberately disagree and explain
why you prefer a different approach. How does it adapt? Does the
final design reflect your input or its original suggestion?
What you're learning: AI as collaborator, not dictator. The brainstorming skill is designed to incorporate your expertise and pushback. The final design should be a convergence of both perspectives, not a copy of Claude's first suggestion.