Superpowers and GSD: How Two Plugins Gave Claude Code a Development Methodology

Out of the box, Claude Code is capable but undisciplined. Give it a task and it starts coding immediately. No questions asked. No plan written. No requirements clarified. It reads the relevant files, makes assumptions, and starts editing. Sometimes that's exactly what you want. Fix this typo. Rename this variable. Add a loading spinner here.

But for anything non-trivial -- a new feature, a refactor, a system that touches multiple files -- you want it to think before it builds. You want requirements gathering, a plan, structured execution, and a review at the end. You want a development methodology.

That's what Superpowers and GSD do. They impose process on an agent that would otherwise skip straight to implementation. And the difference in output quality is not subtle.

The Problem with Unstructured Claude

Let me describe what happens without these plugins. You open Claude Code and say something like "add a blog series scheduling feature." Claude reads your blog system, makes a bunch of inferences about what scheduling means to you, and starts writing code. Maybe it creates a scheduledDate field in the frontmatter. Maybe it builds a cron-style publishing system. Maybe it does something you didn't want at all.

The problem isn't that Claude is bad at coding. It's good at coding. The problem is that it doesn't know what you actually want, and instead of asking, it guesses. An unstructured Claude session is like an unstructured developer -- productive-looking but often building the wrong thing.

I wasted entire sessions this way early on. Claude would build a complete feature, I'd look at it and say "that's not what I meant," and we'd start over. The code was clean. The tests passed. The feature was wrong. That's the worst kind of failure because you don't realize it until you've already invested the time.

The fundamental insight, the one that changed how I use this tool, is that AI agents are only as good as their process. Give Claude a good process and it produces dramatically better results. Superpowers and GSD are that process. I call this context engineering -- structuring the environment around the model matters more than crafting the perfect prompt.

The Superpowers Plugin

Superpowers is a collection of skills that impose structure on how Claude thinks and works. Each one targets a different phase of development.

Brainstorming

The /brainstorm skill is the single most valuable thing I've added to my Claude Code setup. Before any creative or design work, it forces Claude into a Socratic questioning mode. Instead of jumping to solutions, it asks questions.

You type /brainstorm and say "add a blog series scheduling feature." Instead of writing code, Claude asks: What does scheduling mean in this context? Auto-publish on specific dates? Or just ordering posts within a series? Who manages the schedule -- you manually, or should there be automation? What about the existing blog system -- how are posts currently dated and published? Are there draft states? What happens if a scheduled date passes and the post isn't ready?

It resists jumping to solutions. If you try to shortcut the process and say "just build it with a cron job," it pushes back. "Before we decide on implementation, let's make sure we agree on what the feature actually does."

This alone prevents 80% of "I built the wrong thing" moments. The brainstorm takes maybe two minutes. It surfaces requirements you hadn't articulated and edge cases you hadn't considered. By the time it's done, you have a clear, shared understanding of what you're building. That understanding is worth more than any amount of clever code.

Plan Writing

The /write-plan skill takes the output of a brainstorm (or a clear set of requirements) and produces a detailed implementation plan. Not a vague outline. A document with bite-sized tasks, each with a clear deliverable.

The plan becomes a contract between you and Claude. "Here's what we agreed to build. Here are the steps. Here's the order." You review it before any code is written. If something's wrong, you fix it in the plan, not in the code. That's a fundamentally cheaper place to catch mistakes.

Each task in the plan is small enough that you can verify it independently. "Add scheduledDate to the frontmatter schema" is verifiable. "Build the scheduling system" is not. The granularity matters because it gives you review checkpoints throughout implementation, not just at the end.

Plan Execution

The /execute-plan skill runs through the plan in batches with review checkpoints. It doesn't just blindly execute every task. It stops at key points and asks "does this look right?"

This is important because plans don't survive contact with reality perfectly. Sometimes step 4 reveals that step 7 needs to change. The execution skill handles this gracefully. It flags deviations from the plan and asks how you want to proceed rather than silently adapting in ways you might not want.

The batch execution model also keeps the context window manageable. Instead of trying to hold the entire implementation in working memory, it focuses on a few tasks at a time, completes them, and moves on.

Code Review

After implementation, Superpowers includes a code review skill that evaluates the output against the original plan and your project standards. It checks: Did we build what we said we'd build? Does the code follow the conventions in CLAUDE.md? Are there obvious bugs, missing error handling, or accessibility issues?

This is the phase that catches drift. Over the course of a long implementation, it's easy for the work to diverge from the plan. The review brings it back. It's not a replacement for your own review, but it catches the mechanical things so your review can focus on the architectural and product-level concerns.

TDD

The /test-driven-development skill enforces the red-green-refactor cycle. Write tests first. Watch them fail. Implement until they pass. Refactor.

This is one of those things that every developer agrees is a good practice and almost nobody does consistently. When Claude Code does it, there's no temptation to skip the "write tests first" step. The skill enforces the order. Tests get written. They fail. Implementation happens. They pass. Then and only then does refactoring happen.

I don't use this for every task. Quick fixes and simple changes don't need full TDD. But for anything with complex logic -- parsing, state management, data transformation -- this skill produces noticeably more reliable code.

Systematic Debugging

When something breaks, the default Claude behavior is to start making changes and hope one of them fixes the bug. Shotgun debugging. Try this. Nope. Try that. Nope. What about this? It's fast but unreliable, and sometimes it introduces new bugs while fixing the original one.

The systematic debugging skill applies the scientific method. Observe the bug. Form a hypothesis about the cause. Design a test for that hypothesis. Run the test. Draw a conclusion. If the hypothesis was wrong, form a new one. If it was right, implement the fix.

It sounds slow. It's actually faster, because it doesn't waste time on wrong fixes. And the fix it produces is more likely to be correct because it's based on understanding, not trial and error.

The GSD Plugin

If Superpowers is about how to think and code, GSD (Get Stuff Done) is about how to manage a project lifecycle. It's a full framework with 27 commands covering everything from initial idea to completed, verified work.

New Project

The /gsd:new-project command starts with deep context gathering. It doesn't just ask "what are you building?" It researches. It looks at your existing codebase, understands your tech stack, identifies constraints, and creates a PROJECT.md that serves as the source of truth for the project.

This is particularly useful when you're adding a significant feature to an existing system. GSD maps out what exists, what the new feature needs to interact with, and where the integration points are. It's the kind of analysis you'd want a senior developer to do before writing the first line of code on a complex feature.

Roadmapping

After the project is defined, GSD breaks it into phases. Each phase has clear requirements, success criteria, and dependencies on other phases. This is where the big picture gets organized into manageable chunks.

The roadmap isn't just a task list. It's a dependency graph. Phase 2 depends on Phase 1. Phase 3 and 4 can run in parallel. Phase 5 depends on both 3 and 4. This structure prevents the "we built feature B before the foundation for feature A was done" problem that plagues unstructured development.

Phase Planning

The /gsd:plan-phase command takes a single phase from the roadmap and creates a detailed execution plan. This is where the high-level roadmap becomes concrete tasks with dependency analysis, risk assessment, and estimated effort.

If this sounds like it overlaps with Superpowers' /write-plan, it does. The difference is scope. Superpowers plans are great for individual features or focused tasks. GSD phase plans are for coordinating larger bodies of work where task dependencies and execution order matter.

Execution

The /gsd:execute-phase command is where things get built. It uses wave-based parallelized execution -- tasks that don't depend on each other run in parallel via subagents, and each completed wave gates the next. Every meaningful chunk of work gets an atomic commit.

The atomic commit discipline is something I particularly appreciate. Each commit represents a coherent unit of work. If something goes wrong later, you can pinpoint exactly which change caused the issue and revert just that piece. No more "giant commit that touches 40 files and does 7 different things."

Verification

The /gsd:verify-work command runs after a phase is complete. It does a goal-backward analysis: start from the success criteria defined in the roadmap and work backward to verify that the implementation actually achieves them.

This catches a specific failure mode that's common with AI agents: technically correct implementation that doesn't solve the actual problem. The code works. The tests pass. But the feature doesn't do what the user needs. Verification checks the work against the original goals, not just against the test suite.

How They Compose

The real power isn't in either plugin alone. It's in using both together. Each one handles the phase of development it's best at.

Here's the workflow I've settled into for significant features:

Step 1: Brainstorm with Superpowers. /brainstorm to understand what I'm building. Clarify requirements. Surface edge cases. This is where I figure out what "done" looks like.

Step 2: Set up with GSD. /gsd:new-project to create the project structure and context document. This is where Claude maps the existing codebase and identifies integration points.

Step 3: Plan with Superpowers. /write-plan for a detailed task breakdown. The plan is informed by both the brainstorm output and GSD's project context, and it benefits from plan mode's explore-first approach. It's specific, granular, and reviewable.

Step 4: Execute with GSD. /gsd:execute-phase for wave-based parallel execution with atomic commits. The tasks come from the Superpowers plan, but GSD handles the execution mechanics -- parallelization, commit discipline, and progress tracking.

Step 5: Review. Code review from Superpowers against the plan and CLAUDE.md standards. Verification from GSD against the project goals.

It's a full development pipeline. Each plugin handles the phase it's best at. Superpowers is better at thinking -- brainstorming, planning, reviewing. GSD is better at doing -- project setup, execution, verification. Together they cover the entire lifecycle.

Brainstorming in Practice

Let me walk through what this actually looks like. I'm going to describe a real session because abstract descriptions don't convey the feel of working this way.

I type /brainstorm and say "I want to add a blog series scheduling feature to my portfolio site."

Claude doesn't start coding. It starts asking.

"What does 'scheduling' mean to you in this context? Are you looking for automatic publishing on specific dates, or manual control over publish order within a series?"

I say automatic publishing. Posts should go live on their scheduled date without me doing anything.

"How does your current blog system handle publishing? I can see you have a published boolean in frontmatter. Is there a build pipeline that could trigger on a schedule, or would this need a server-side component?"

Good question. My site is statically generated. There's no server to run a cron job. I say that.

"So we'd need either a CI/CD scheduled rebuild, or a client-side approach that uses the scheduled date to conditionally show or hide posts at render time. The CI approach means the post exists on the server before its date but isn't built into the site yet. The client approach means the post is always built but only displayed after its date, which has SEO and preview implications. Which tradeoff do you prefer?"

This is the kind of question I wouldn't have thought to ask myself until I was halfway through implementation and realized my approach had a fundamental constraint I hadn't considered. The brainstorm surfaced it before any code was written.

We go back and forth for another minute or two. By the end, I have a clear spec: use a scheduledDate field in frontmatter, build a GitHub Actions workflow that runs daily and triggers a rebuild, filter out future-dated posts at build time, and add a "scheduled" status indicator to the admin view.

Total time for the brainstorm: about two minutes. Value: I didn't build a client-side date-checking system that would have been wrong for my architecture.

Why Structure Matters for AI

Here's the thing about Claude Code that took me a while to internalize. It's not a tool that needs better prompts. It's a tool that needs better process.

Prompting is important. I'm not dismissing it. A clear, specific prompt will always outperform a vague one. But there's a ceiling to what prompting alone can achieve. You can write the most detailed prompt in the world, and Claude will still sometimes make wrong assumptions, skip important considerations, or barrel ahead without checking its understanding.

Process is what removes those failure modes. A brainstorm step means assumptions get surfaced and checked. A planning step means the approach is reviewed before implementation begins. Execution checkpoints mean drift gets caught early. A review step means the output is evaluated against the original goals.

This is not a new idea. It's how good development teams already work. Requirements gathering, design review, sprint planning, code review -- these are established practices because they work. They prevent expensive mistakes by catching problems early when they're cheap to fix.

What's new is applying this to an AI agent. Claude Code doesn't naturally follow a development methodology. It follows a "read the prompt, think briefly, start coding" methodology. That's what an unstructured developer does too, and it has the same failure modes: wrong assumptions, missing requirements, wasted effort.

Superpowers and GSD give Claude the same guardrails that a good development process gives a human team. The guardrails don't slow things down. They speed things up, because they prevent the rework that eats most of the time on any non-trivial project.

The Overhead Is Worth It

I know what the objection is. "All that brainstorming and planning is overhead. I just want to build the thing."

I had the same reaction. For about two weeks, I resisted the planning steps and went straight to implementation. I was faster in the short term and dramatically slower in the aggregate because I kept building things that needed to be redone.

Here's the math. A brainstorm takes about two minutes. A plan takes about three minutes. Together, five minutes of upfront work. The feature implementation that follows is typically 20-40 minutes depending on complexity.

Without the brainstorm and plan, I'd save those five minutes. But about one in three features would need significant rework because I built the wrong thing, or built it the wrong way, or missed a requirement that surfaced halfway through. That rework costs 15-30 minutes, sometimes more.

Expected time without structure: 30 minutes implementation + (0.33 * 20 minutes rework) = about 37 minutes on average.

Expected time with structure: 5 minutes planning + 25 minutes implementation (faster because the plan is clear) + (0.05 * 15 minutes rework) = about 31 minutes on average.

The structured approach is faster. Not by a huge margin on any single feature, but consistently, across every feature, compounding over days and weeks. And the rework rate drops from roughly one in three to roughly one in twenty. That alone changes how the work feels. You're making forward progress instead of circling back.

It took several wasted sessions for this to click. I'm a "just start building" person by temperament. The discipline of stopping to brainstorm and plan felt unnatural. But the results were so obviously better that I couldn't argue with them. Now I do it every time, and the few times I skip it out of impatience, I usually regret it.

The Composition Effect

There's something that happens when you use Superpowers and GSD together that's more than the sum of their parts.

Each plugin individually is good. Superpowers makes Claude think more carefully. GSD makes Claude execute more methodically. But when they compose, you get a feedback loop. The brainstorm informs the plan. The plan structures the execution. The execution produces work that's reviewable against the plan. The review feeds back into the next iteration.

It's the same feedback loop that makes agile development work (when it actually works, not the cargo-cult version). Short cycles. Clear goals. Regular review. Course correction based on real output, not projections.

The difference is that with an AI agent, the cycle time is minutes, not weeks. You brainstorm, plan, build, and review a feature in under an hour. If the review reveals problems, you iterate immediately. There's no sprint boundary, no standup, no two-week delay between identifying a problem and addressing it.

This is what I mean when I say these plugins gave Claude Code a development methodology. Not a theoretical one. A practical one that runs in my terminal and produces better software than the alternative.

What This Doesn't Fix

I want to be honest about the limitations. Superpowers and GSD don't make Claude Code perfect. They make it structured, and structure prevents a specific class of errors -- wrong assumptions, missing requirements, undisciplined execution. But there are failure modes they don't address.

Claude can still write buggy code. The logic can be wrong even when the requirements are right. Code review catches some of this, but not all. You still need to review the output with your own eyes.

Claude can still hallucinate APIs or library features that don't exist. Structure doesn't prevent the model from confidently using a function that was never part of the library. Testing catches this, which is why TDD with coding agents is valuable, but it's still something to watch for.

And for small, well-defined tasks, the overhead of brainstorming and planning genuinely isn't worth it. "Fix this CSS alignment bug" doesn't need a brainstorm session. "Rename this component" doesn't need a plan. Use the tools when the task warrants them. Most of the time, that means features, refactors, and any task where the requirements aren't obvious.

Closing

The best AI coding workflow isn't about writing better prompts. It's about having a better process.

I spent months using Claude Code as a fast-but-chaotic coder. It would build impressive things quickly, and a meaningful fraction of those things would need to be rebuilt because we hadn't agreed on what "the right thing" was before construction started.

Superpowers and GSD fixed that. They gave Claude Code a development methodology -- brainstorm, plan, execute, review -- and the output quality improved immediately. Not incrementally. Immediately. The first feature I built with the full pipeline was the first feature I didn't need to redo.

These plugins aren't magic. They're process. The same process that good engineering teams have been using for decades, adapted for an AI agent that lives in your terminal. The fact that it works so well says something about both the capability of the underlying model and the importance of giving capable agents the right structure to work within.

If you're using Claude Code without any plugins, you're getting maybe 60% of what it can do. Install Superpowers. Install GSD. Spend a week using the brainstorm-plan-execute-review cycle. Then try going back to unstructured sessions. You won't want to. If you want to see how these plugins fit into a complete end-to-end workflow, read how I ship a feature in 45 minutes.