Super Brainstorm: The Skill That Makes Your AI Think Before It Builds

You tell your AI agent “add notifications to the app.” It immediately starts writing code. Twenty minutes later, you have a half-built notification system that uses WebSockets when SSE would have been fine, sends emails you never asked for, and stores notifications in a schema that does not match your existing data model.

The problem is not that the agent is bad at coding. The problem is that it skipped the most important step: understanding what to build.

Super Brainstorm fixes this by forcing a structured design interview before any code is written. The agent reads your codebase, asks questions one at a time, and refuses to move forward until both of you are 100% confident in every design decision.

---

Why “Just Build It” Fails

AI agents are biased toward action. Given a feature request, their default behavior is to start writing code immediately. This works fine for trivial tasks - fix a typo, rename a variable, add a missing import.

But for anything with design decisions - a new feature, a refactor, a system redesign - jumping straight to code means:

• Assumptions baked into architecture. The agent picks a database, a transport protocol, a component structure - all without asking. Half the time it guesses wrong.
• Wasted context on rework. You spot the wrong assumption 200 lines in, and now the agent has to undo and redo with depleted context.
• Missing edge cases. The happy path works. But what happens when the user has 10,000 unread notifications? Or when the parent comment gets deleted? Nobody asked.

Super Brainstorm inverts this. It operates entirely in plan mode. No code, no scaffolding, no implementation - just structured thinking and interviewing until the design is solid.

---

How It Works

When you invoke absolute-brainstorm, the agent follows a strict 10-phase process. Here is what each phase does and why it matters.

Phase 1: Deep Context Scan

Before asking a single question, the agent reads everything it can find about your project - README, docs, CLAUDE.md, recent git commits, package manifests, project structure. It is looking for existing patterns, tech stack decisions, and conventions that constrain the design.

This sounds obvious, but most agents skip it. They ask “what database are you using?” when the answer is sitting in prisma/schema.prisma. Super Brainstorm eliminates these wasted questions by searching the codebase first.

Phase 2: Codebase-First Intelligence

This is the core differentiator. Before every question, the agent checks whether the codebase already has the answer.

• “What testing framework?” - Check jest.config.ts. Do not ask.
• “How do you handle auth?” - Search for auth middleware. Do not ask.
• “What visual style do you want?” - Code cannot answer this. Ask.

When the agent does find the answer in code, it tells you what it found: “I see you’re using NextAuth with JWT sessions and role-based access from your middleware. I’ll design around that.” This builds trust and saves time.

Phase 3: Scope Assessment

If the request hides multiple independent systems (“build a platform with chat, billing, and analytics”), the agent flags it immediately and helps decompose into sub-projects. Each one gets its own brainstorm cycle.

Phase 4: Relentless Interview

The heart of the skill. One question at a time, depth-first through the design tree. Every question is preceded by ultrathink-level reasoning. The agent resolves dependencies between decisions in order - it will not ask about notification delivery channels before understanding what events trigger notifications.

The key rules:

• One question at a time. Never overwhelm with a list.
• Multiple choice when possible. Easier to answer. Always includes a recommendation marked (Recommended) with rationale.
• Codebase check before every question. Only ask what code cannot tell you.
• Never fake options. If the answer is obvious, present it directly with reasoning for why alternatives were dismissed.
• Mutual 100% confidence required. After each decision, both the AI and the user must be fully confident. If either side has doubt, the agent probes deeper.

That last point is critical. The agent does not just wait for you to say “sounds good.” It actively checks its own confidence. If it has private doubts about a decision - maybe it is not sure the codebase supports a particular pattern, or it suspects an edge case it has not surfaced - it stops and asks rather than burying the uncertainty.

Phase 5: Approach Proposals

Only when there is a genuine design fork. If the answer is clear, the agent presents it directly and explains why alternatives were dismissed. No padding with fake options.

When there is a real fork, each approach gets: what it is, pros and cons, when you would pick it, and a clear (Recommended) marker.

Phase 5.5: Confidence Self-Check

Before presenting any design, the agent runs a mandatory self-verification:

1. Ultrathink through every decision made during the interview
2. Check each one: “Am I 100% sure, or am I filling gaps with assumptions?”
3. If any decision falls below 100%, go back and ask more questions
4. Explicitly communicate confidence state to the user

This prevents the common failure mode of presenting a design with hidden doubts, then discovering during implementation that a core assumption was wrong.

Phase 6-9: Design, Spec, Review

The agent presents the design section by section, getting approval at each step. Then it writes a formal spec to docs/plans/, dispatches a reviewer subagent to check for completeness and consistency, and gets your final sign-off.

Phase 10: Hand Off to Absolute-Human

Once the spec is approved, the agent recommends delegating execution to absolute-human - a companion skill purpose-built to take validated specs and execute them through dependency-graphed sub-tasks, parallel waves, and TDD verification.

This creates a clean handoff: absolute-brainstorm designs, absolute-human builds.

---

The 100% Confidence Gate

The most important feature of absolute-brainstorm is the mutual confidence requirement. Traditional brainstorming ends when the conversation feels “done.” Super Brainstorm ends when both parties are provably confident.

This means:

• The agent does not advance when it has private doubts. If it suspects an edge case it has not surfaced, it asks about it rather than hoping for the best.
• The user does not get rushed. If you say “I think maybe Kafka?” the agent does not treat that as a decision. It probes: what is the message volume, what are the latency requirements, have you used Kafka before?
• Hesitation is a signal, not noise. Words like “maybe,” “I think,” “probably,” and “not sure” trigger deeper questioning rather than acceptance.

The result is a spec where every decision has been examined from both sides. No hidden assumptions, no “we’ll figure it out during implementation.”

---

What Super Brainstorm Is Not

It is not a casual ideation tool. It will not help you brainstorm names for your startup or explore vague product directions. It is a structured engineering design process.

It is also not for trivial tasks. If the solution is obvious - fix a bug, rename a function, update a dependency - skip absolute-brainstorm and just do it.

Use it when the task has real design decisions: new features, architecture changes, system redesigns, greenfield projects, major refactors. The threshold is simple: if you would whiteboard it with a colleague before coding, you should absolute-brainstorm it with your agent.

---

Getting Started

Install the skill:

npx skills add AbsolutelySkilled/AbsolutelySkilled --skill absolute-brainstorm

Then invoke it when you have a feature to design:

/absolute-brainstorm I want to add a real-time collaboration system to my app

The agent will enter plan mode, scan your codebase, and start the interview. Answer one question at a time. Push back when something feels wrong. The agent will keep going until you are both confident.

For best results, pair it with these companion skills:

• absolute-human - takes the approved spec and executes it with parallel task waves and TDD
• writing-plans - alternative execution path if you prefer detailed implementation plans over the full absolute-human lifecycle
• clean-architecture - grounds the design in Clean Architecture principles
• system-design - adds distributed systems expertise for infrastructure-heavy designs

---

The Design-First Mindset

The best developers spend more time thinking than typing. Super Brainstorm brings that discipline to AI-assisted development.

Every project - even the “simple” ones - goes through the interview. A todo app, a single-function utility, a config change. “Simple” projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but it happens.

The payoff is clear: less rework, fewer surprises during implementation, and specs that a staff engineer would approve. Your agent stops guessing and starts understanding.

Once your spec is ready, read about the execution side: Absolute-Human: An AI-Native SDLC That Actually Ships - how the companion skill takes your validated design and builds it with parallel wave execution and TDD.