Skip to main content
/brainstorm is the entry point to every new feature. It runs the brainstorming skill and adds session coordination on top: stage tracking, a hard gate against premature implementation, and a clean hand-off to /plan.

​
When to use

Use /brainstorm when:
  • Starting any new feature, component, or significant change
  • You have an idea but no approved design yet
  • You want to explore 2–3 approaches before committing to one
Do not use /brainstorm when:
  • A design doc already exists and is approved — go to /plan instead
  • You are fixing a small, well-understood bug — go to /implement with a confidence-check
/brainstorm requires Planning Mode to be active in your Antigravity settings. SuperAntigravity will prompt you to enable it if it isn’t.

​
Session state

At the start of each session, and after each major step, SuperAntigravity outputs its current state: 
Session: /brainstorm
Stage: [question N of ~5 | proposing approaches | presenting design | approved]
Design doc: [not started | in progress | saved at path]
This keeps you oriented — you always know how far along the design is and where the output will be saved.

​
Orchestration steps

1

Announce

SuperAntigravity tells you: “Starting /brainstorm. I will not write any code until you approve the design.” This sets the expectation for the session.
2

Explore project context

Checks existing files, docs, and recent commits to understand what already exists. For greenfield projects this step is skipped.
3

Ensure Planning Mode

Prompts you to switch to Planning Mode in Antigravity settings if it isn’t already active.
4

Ask clarifying questions

Asks questions one at a time to understand purpose, constraints, and success criteria. Questions stop when SuperAntigravity can restate the goal in one sentence, knows the top constraint, and understands the success criteria — typically 3–5 questions. Multiple-choice questions are preferred where possible.
5

Propose 2–3 approaches

Presents multiple approaches with trade-offs, leads with its recommended option, and explains why. You choose which direction to take.
6

Present the design

Walks through the design section by section — architecture, components, data flow, error handling, testing. Asks for your approval after each section so you can course-correct early rather than reviewing a large design at the end.
7

Write the design doc

Saves the approved design to docs/plans/YYYY-MM-DD-<topic>-design.md and commits it.
8

Gate check

Confirms the design doc exists at the expected path before proceeding. This is a precondition for the next stage.
9

Transition to /plan

Loads the writing-plans skill and hands off to /plan. This is the only skill loaded after brainstorming — no implementation skills are loaded here.

​
The hard gate

If you say “just build it” or “skip the design”, SuperAntigravity stops and responds:
“SuperAntigravity requires design approval before implementation. This prevents wasted effort. The design will take 10–15 minutes and saves hours of rework. Shall we continue?”
This gate cannot be bypassed. An implementation action — writing any file that will be part of the product, running npm init, generating scaffolding — is blocked until you explicitly approve a design.
The hard gate applies to every project regardless of perceived simplicity. “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 must exist and be approved.

​
Handling partial approval

If you approve the design with modifications, SuperAntigravity incorporates the changes, re-presents only the changed section, and continues. It does not re-present sections you already approved.

​
Completion criteria

The brainstorm session is complete when all three conditions are met:
  • Design doc saved to docs/plans/
  • You have explicitly approved the design (acknowledgement is not enough)
  • Next step communicated — you know to run /plan

​
Skills invoked

SkillWhen invoked
brainstormingPrimary — owns the full brainstorm process
deep-researchWhen feasibility research is needed before proposing approaches
architecture-designWhen the feature requires system design decisions

​
What comes next

After approval, SuperAntigravity transitions directly to /plan to create the implementation plan. The design doc produced here becomes the source of truth for the plan.
If you partially change your mind during /plan or /implement, the correct path is to return to /brainstorm for the new scope — not to silently modify the plan. This keeps the design doc and plan in sync.

Build docs developers (and LLMs) love

Get started for freeTalk to us