Superpowers Brainstorming: The Design-First Gate for AI Agents

Why Agents Need Permission to Think Before They Act

Give a capable AI agent a vague task and it will do what capable agents always do: start working immediately. It will ls something, edit something, maybe restart something — all before anyone has agreed on what "done" means. The superpowers brainstorming skill exists to stop that. It is the first gate in the Superpowers skill library: before any non-trivial task, the agent must explore intent, requirements, and approach, then present a design and get it approved. Only then does implementation begin.

This article is a deep dive into how the skill works, why its central rule is written as an unconditional hard gate, and how it shaped a real infrastructure investigation on one of our production boxes.

What the Brainstorming Skill Actually Does

The skill’s one-line job: turn ideas into fully formed designs through collaborative dialogue. It triggers on research tasks, feature design, system configuration, creative work — any goal requiring more than a couple of tool calls. Notably, it is not restricted to coding. A research question, a config change, and a data migration all go through the same funnel.

Five operating principles govern the dialogue:

• One question at a time. No interrogation walls. Each question refines purpose, constraints, or success criteria.
• Multiple choice preferred. "Should the audit be read-only, or may it make changes? (a/b/c)" is easier to answer than an open prompt.
• YAGNI ruthlessly. Scope that wasn’t asked for gets removed at design time, not discovered at deploy time.
• Explore alternatives. Every design comes with 2–3 candidate approaches and a recommendation with reasons.
• Incremental validation. The design is presented in sections scaled to complexity — a few sentences for simple parts, up to 200–300 words for nuanced ones — with approval requested after each.

The HARD-GATE: No Implementation Without an Approved Design

The skill’s load-bearing element is a rule wrapped in literal <HARD-GATE> tags so the agent cannot treat it as advice:

<HARD-GATE>
Do NOT invoke any implementation skill, write any code,
execute any plan, or take any action until you have presented
a design and the user has approved it. This applies to EVERY
non-trivial task regardless of perceived simplicity.
</HARD-GATE>

The emphasis on "regardless of perceived simplicity" is deliberate. The skill names its own anti-pattern — "This is too simple to need a design" — and pre-empts it: simple tasks are precisely where unexamined assumptions cause the most wasted work, because nobody reviews them. The gate doesn’t demand a fifteen-page spec; for a genuinely simple change the design can be three sentences. What is non-negotiable is that the sentences get presented and approved before a tool fires.

The Checklist: Eight Steps From Context to Plan

The skill operationalizes brainstorming as an ordered checklist:

Two details make this survive contact with real work. First, design-doc-as-memory: the approved spec lives on disk with a date, so a session three months from now can recover why an approach was chosen, not just what was built. Second, the design is explicitly shaped for delegation — work is broken into units with clear boundaries that are independently understandable and verifiable, which is exactly the granularity a fresh subagent needs.

Case Study: The SYNAS Docker Audit

SYNAS is one of our always-on boxes: it hosts production services, and it is the kind of machine you do not jab at. Its SSH access is fenced by an nftables drop-only ruleset locked to a known IP range, and Docker networking depends on that firewall behaving exactly as configured — a careless systemctl enable nftables here is not an inconvenience, it is an outage plus a locked-out admin.

The task arrived in the worst possible form for an agent: "look into Docker on SYNAS." Five words, no success criteria. An unbracketed agent would have been typing docker ps before lunch and "cleaning up" stopped containers by dinner.

Brainstorming turned the demand into a scoped audit:

• Explore context first. Following the skill’s delegate_task pattern, a read-only survey subagent was dispatched with an explicit boundary — "Report: what exists, what’s configured, what’s missing. Do NOT make changes." Inventory, restart policies, published ports, volumes, and log configuration came back as facts, not guesses.
• One question at a time. What is the audit actually for — security posture, resource hygiene, or migration prep? What may go down during the audit (answer: nothing)? Is the deliverable a report or a remediated system?
• Three approaches, recommendation first. (A) Static, read-only audit with a written findings report; (B) audit plus applied fixes in the same pass; (C) audit and container rebuild. The skill’s recommendation — A — won on blast-radius arithmetic: on a box where a wrong command can flush the firewall’s Docker rules, the value of speed is smaller than the cost of being wrong.
• Design in sections. Scope, method, per-finding risk classification, verification method, and an explicit rollback plan — approved section by section before any state-changing command ran.

The findings themselves mattered less than the shape of the run. Every risky action that wasn’t taken during brainstorming is invisible in the incident log, because there wasn’t one. The audit produced a prioritized findings report; remediation became its own later task, each item a bounded unit that could be handed to a subagent with the design doc as its brief. That last part is not incidental — the skill designs work units specifically so they can be delegated.

When to Skip, When to Insist

The gate is strict, so agents learn to negotiate with it. The skill ships a rationalization table specifically to shut those down:

In practice the line is simple. Skip only when the task is a single tool call, fully reversible, and unambiguous — checking a version, reading a file, listing processes. Insist whenever any of three things is true: the work has blast radius (production systems, shared data, other people’s sessions); the request contains ambiguity a wrong guess would expose; or the work spans enough steps that a subagent might inherit it. The SYNAS audit was all three at once.

Related Deep Dives in the Series

Brainstorming is the front door of the Superpowers workflow, and it hands off explicitly:

• Superpowers Writing Plans — takes the approved design document and turns it into a step-by-step implementation plan with verification at each step.
• Superpowers Executing Plans — the disciplined execution phase once a plan exists and work begins.
• Superpowers Subagent-Driven Development — dispatches each bounded work unit to a fresh subagent whose brief is the design doc; this is why brainstorming designs in independently verifiable units.

The sequence is deliberate: design → plan → execute, each phase gated by human approval. The brainstorming skill is where the most expensive kind of error — confidently building the wrong thing — gets eliminated while it is still cheap.