Why Does Your AI Agent Keep Building the Wrong Thing?

The Problem: Your AI Agent Is a Fast, Wrong Builder

I was working on a project last month, trying to add a simple notification feature to a web app. I told my AI coding agent, "Add a notification system for user alerts." The agent immediately started writing code. Within minutes, it had scaffolded a complex, real-time WebSocket-based notification center with a full database schema, user preferences, and a bell icon in the header.

The problem? I just needed a simple email notification for password resets.

This is a common pain point. AI agents are incredibly powerful at generating code, but they often lack the crucial step of understanding what to build before they start building. They jump straight from a vague idea to implementation, leading to:

• Wasted time and tokens on code that gets thrown away.
• Misaligned features that don't solve the actual user problem.
• Scope creep where "simple" tasks balloon into complex systems.
• Frustration for both the developer and the AI, as the conversation devolves into a series of corrections.

The root cause is a missing design phase. Humans naturally think through requirements, constraints, and trade-offs before coding. AI agents, by default, are optimized for speed and generation, not for collaborative clarification. They treat every request as a direct instruction to execute, not as the beginning of a conversation.

A good solution needs to force a pause. It should create a structured dialogue where the agent explores your intent, asks clarifying questions, proposes different approaches, and gets your explicit approval on a design before a single line of code is written. This turns the agent from a fast, autonomous coder into a collaborative design partner.

Introducing the Brainstorming Skill for AI Agents

This is where the Brainstorming skill comes in. It's not a code generator or a UI component library. It's a process skill—a set of instructions that tells your AI agent how to behave before it starts any creative or implementation work.

Think of it as a mandatory pre-flight checklist for your agent. When activated, the agent is required to:

1. Explore the project context first (looking at existing files, docs, and recent commits).
2. Ask clarifying questions one at a time to understand your true intent, constraints, and success criteria.
3. Propose 2-3 different approaches with clear trade-offs and a recommendation.
4. Present a structured design for your approval, section by section.
5. Write and commit a formal design spec only after you've approved it.

Only after this entire process is complete does the agent transition to the implementation phase, invoking a separate "writing-plans" skill. This creates a hard gate between design and execution.

The skill's core philosophy is captured in its anti-pattern warning: "This Is Too Simple To Need A Design." Even for a "simple" todo list or config change, the process forces you to examine assumptions. A design for a simple feature might just be a few sentences, but the act of writing it down and getting approval prevents the most common type of wasted work: building the wrong simple thing.

How This Skill Changes Your Workflow

Without this skill, a typical interaction might look like this:

You: "Add a dark mode toggle."
Agent: Immediately starts modifying CSS variables, adding a toggle component, and setting up local storage persistence.
You: "Wait, I just wanted a simple CSS class swap for now."

With the Brainstorming skill active, the conversation becomes collaborative:

You: "Add a dark mode toggle."
Agent: "Let me first check the current project structure... I see we're using React and Tailwind CSS. Before I design this, a few questions: Should the preference persist across sessions? Should it follow the system's OS-level preference initially? And what's the scope—just the main app shell, or all third-party components too?"
You: "Just the app shell for now, and yes, persist it."
Agent: "Great. I see two main approaches: 1) Use Tailwind's dark: variant with a simple context provider, or 2) Use CSS custom properties for more granular control. I recommend option 1 for faster implementation. Here's the design: A ThemeProvider context will manage the state, a Toggle component in the header will switch it, and we'll use localStorage for persistence. Does this section look right?"

This shift is profound. You move from being a corrector of mistakes to a director of a process. The agent's intelligence is channeled into understanding and planning, not just generating.

When to Use This Skill (And When Not To)

Use this skill when:

• You are starting any new feature, component, or significant modification.
• The request is ambiguous or could be interpreted in multiple ways.
• You want to avoid scope creep and ensure the agent builds exactly what you need.
• You're working on a team and need a documented design rationale.
• The task involves UI/UX, architecture decisions, or behavioral changes.

This skill might be overkill when:

• You are performing a purely mechanical, well-defined task (e.g., "rename this variable everywhere," "run the test suite").
• You are fixing a single, obvious bug with a clear, singular solution.
• You are in a rapid prototyping phase where speed of exploration is more important than correctness, and you're willing to discard code frequently.

The skill's repository notes that it is designed for "creative work." If the task has no creative ambiguity—no "how should we build this?" questions—it likely doesn't need this process.

What to Inspect Before Using It

Before integrating this skill into your agent's workflow, consider the following:

1. Process Overhead

This skill adds steps. For a trivial task, it can feel slow. Evaluate if the time saved by avoiding rework outweighs the time spent in the design dialogue. For most non-trivial features, it does.

2. Repository Signals

The skill comes from the obra/superpowers repository, which has a significant number of stars (227k+), indicating strong community validation. The license is permissive. However, always review the SKILL.md file yourself to understand the exact process it enforces. The skill's landing page provides a good overview.

3. Safety and Control

The skill includes a HARD-GATE directive: the agent must not invoke any implementation skill until the design is approved. This is a critical safety feature that keeps you in control. It also includes a "Spec Self-Review" step where the agent checks its own design document for placeholders, contradictions, and ambiguity before you even see it.

4. Integration with Your Tools

The skill assumes a development environment where the agent can read files (check files, docs, recent commits) and write documents (save to docs/superpowers/specs/...). Ensure your agent setup supports these actions. The final step invokes a "writing-plans" skill, so you'll need that skill (or a similar one) available for the full cycle.

5. Adaptability

The process is a framework, not a rigid script. The agent is instructed to "scale each section to its complexity." A design for a button color change will be a short conversation; a design for a new authentication system will be a detailed document. The skill adapts to the scope.

The Bottom Line

The biggest risk with powerful AI coding agents isn't that they're slow—it's that they're fast in the wrong direction. The Brainstorming skill acts as a necessary circuit breaker, inserting a human-in-the-loop design phase that aligns the agent's output with your actual intent.

It transforms the agent from an autonomous coder into a collaborative partner. The result is less wasted effort, better-architected solutions, and a development process where you feel in control. If you've ever felt like you're spending more time correcting your AI than coding with it, this skill is worth a serious look.

You can explore the full details and implementation notes on the Brainstorming skill page.