Inside Anthropic’s Superpowers Brainstorming: Enforcing Design Gates to Stop AI from Jumping Straight to Code

I've been using Anthropic’s official Superpowers skill and find it remarkably effective. Its core purpose is to turn a vague "idea" into a concrete "design" before any code is written.

HARD‑GATE is enforced via the following snippet:

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

Even a simple todo list or a one‑function tool must go through this gate.

The skill labels the anti‑pattern "This Is Too Simple To Need A Design" and warns that the easiest failures come from projects mistakenly judged as simple. An example: a request to "add a field" often expands into migrations, caches, permissions, and reports because nobody clarified the impact before coding.

9‑Step Checklist: Turning Conversational Design into a State Machine

Explore project context (files, docs, recent commits).

If the topic involves visual issues, provide a separate visual message.

Ask one clarification question at a time – understand purpose, constraints, success criteria.

Propose 2‑3 methods, include trade‑offs and a recommendation.

Present design in sections; obtain approval for each before proceeding.

Save the design document to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md.

Self‑review the spec (place‑holder scan, consistency, scope, ambiguity).

User reviews the completed spec.

Invoke the writing‑plans skill to move to implementation planning.

The skill also includes a DOT‑format diagram that acts as a state machine, defining the current step, next‑step conditions, and fallback paths.

The terminal state is invoking writing‑plans . Do NOT invoke frontend‑design , mcp‑builder , or any other implementation skill.

Thus, after brainstorming, the only allowed transition is to the planning stage.

One Question at a Time: Fighting the Model’s “Information Flood”

One question at a time. Don't overwhelm with multiple questions.

Multiple choice preferred. Easier to answer than open‑ended when possible.

The model normally asks five open‑ended questions in a row (e.g., database, frontend framework, auth, offline support, target users), leaving the user confused. The skill forces each message to contain a single question, preferably with selectable options, turning requirement gathering into a step‑by‑step interview.

YAGNI Ruthlessly: Cutting Waste in the Design Phase

YAGNI ruthlessly. Remove unnecessary features from all designs.

Traditionally YAGNI is applied during coding; here it is moved to design, so a line removed from a spec saves a week of implementation effort.

Visual Companion: Tool, Not Mode

Available as a tool — not a mode. Accepting the companion means it's available for questions that benefit from visual treatment; it does NOT mean every question goes through the browser.

The test is simple: "Would the user understand this better by seeing it than reading it?" If yes, use a browser (mockup, wireframe, diagram); if no, stay in the terminal.

UI topics ≠ visual problems – conceptual questions stay textual.

Capability ≠ necessity – just because a tool can do something doesn’t mean you must.

Scope Control Before Detailed Questions

Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.

This forces the model to recognize when a request is too large and to suggest breaking it into smaller sub‑projects.

Self‑Review + User Review: Double Gates

After writing the spec, the skill requires a self‑review with four checks:

Placeholder scan: any TBD, TODO, vague requirements?

Internal consistency: do sections contradict each other? Does architecture match feature descriptions?

Scope check: is the spec focused enough to produce an implementation plan?

Ambiguity check: resolve any requirement that can be interpreted in two ways.

Only after the AI passes this self‑review does it hand the spec to a human for user review, ensuring the human focuses on high‑level decisions rather than low‑level errors.

Takeaways for Building AI‑Assisted Workflows

Three key insights emerge:

Make the process explicit. Separate design, planning, and implementation into distinct skills with clear entry/exit points.

Push constraints forward. HARD‑GATE, early YAGNI, and scope assessment catch mistakes seconds after they appear, saving days of work.

Leave judgment to the user. The skill only orders questions; the user still decides which option or feature to keep.

In short, the real competitive edge in AI‑assisted coding is not a smarter model but a well‑engineered workflow that releases the model’s power at the right time, in the right granularity.