Understanding the Constraints of the Brainstorming Skill in Superpowers

The brainstorming skill enforces six strict constraints—including a mandatory pre-condition, hard gate, ordered checklist, and terminal state—that prevent any implementation work until a user-approved design is documented and persisted.

The constraints of the brainstorming skill in the obra/superpowers repository create a rigid, process-oriented workflow designed to eliminate shortcutting straight to code. This skill acts as a mandatory checkpoint that every assistant must traverse before invoking any implementation-oriented capabilities.

What Is the Brainstorming Skill?

The brainstorming skill is defined in skills/brainstorming/SKILL.md as a process-oriented skill that must be obeyed exactly before any creative or implementation work begins. Unlike advisory skills, this skill functions as a hard gate in the assistant's execution flow, physically blocking subsequent actions until its constraints are satisfied.

Core Constraints of the Brainstorming Skill

Mandatory Pre-Condition

The skill functions as a mandatory pre-condition that must be invoked before any creative work—including feature addition, component building, or behavior change. According to the command definition in commands/brainstorm.md (lines 2‑3), the description explicitly states: "You MUST use this before any creative work."

# commands/brainstorm.md

---
description: "You MUST use this before any creative work …"
disable-model-invocation: true
---
Invoke the superpowers:brainstorming skill and follow it exactly as presented to you

Hard Gate Blocking Implementation

A <HARD-GATE> block in skills/brainstorming/SKILL.md (lines 14‑16) explicitly prevents any implementation-type skill from being invoked until a design is approved and persisted. This constraint creates a physical barrier in the execution flow.

# skills/brainstorming/SKILL.md

<HARD-GATE>
Do NOT invoke any implementation skill … until you have presented a design and the user has approved it.
</HARD-GATE>

Ordered Checklist Execution

The skill enforces an ordered checklist of six steps that must be executed sequentially without deviation. Defined in skills/brainstorming/SKILL.md (lines 22‑32), the checklist mandates specific actions ranging from context exploration to skill transition.

## Checklist

1. **Explore project context** …
2. **Ask clarifying questions** …
3. **Propose 2‑3 approaches** …
4. **Present design** …
5. **Write design doc** …
6. **Transition to implementation** – invoke writing‑plans skill

Terminal State Transition

The skill has a terminal state that permits only one possible next action. According to skills/brainstorming/SKILL.md (lines 55‑56), the only permissible next step after completing the brainstorming workflow is invoking the writing-plans skill. No other implementation skills—such as frontend-design or mcp-builder—may be called directly.

digraph brainstorming {
    …
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Invoke writing-plans skill";
}

Design Approval Requirement

Before transitioning to documentation, the skill requires explicit user approval of the presented design. The flow diagram in skills/brainstorming/SKILL.md (lines 48‑51) includes a decision node labeled "User approves design?" where a "no" response loops back to revision, while a "yes" response proceeds to documentation.

Documentation Persistence

The final constraint requires documentation persistence to a specific file path format. According to skills/brainstorming/SKILL.md (lines 80‑84), the design document must be saved to docs/plans/YYYY-MM-DD-<topic>-design.md and committed to the repository.

# (inside the assistant’s response after design approval)

✅ Design approved.

🗒️ Writing design document to `docs/plans/2026-02-16-feature-x-design.md`…

🔧 Now invoking the next step:
use skill superpowers:writing-plans

Implementation Details in the Source Code

The constraints are encoded across two primary files in the obra/superpowers repository:

• skills/brainstorming/SKILL.md: Contains the full skill definition, including the <HARD-GATE> block, ordered checklist, flow diagram, and documentation requirements.
• commands/brainstorm.md: Defines the command interface that triggers the skill, including the disable-model-invocation: true flag that prevents the model from bypassing the skill through autonomous invocation.

Summary

• The brainstorming skill acts as a mandatory pre-condition that must execute before any creative or implementation work.
• A hard gate physically blocks implementation skills until user approval is obtained.
• An ordered checklist of six steps must be completed sequentially without deviation.
• The skill has a terminal state permitting only the writing-plans skill as the next step.
• Explicit user approval and documentation persistence to docs/plans/YYYY-MM-DD-<topic>-design.md are required before transition.

Frequently Asked Questions

What happens if I try to skip the brainstorming skill?

If you attempt to invoke an implementation skill such as frontend-design or mcp-builder without completing the brainstorming workflow, the <HARD-GATE> block in skills/brainstorming/SKILL.md will block the invocation. The system enforces this constraint by checking that a design has been presented and explicitly approved before allowing any code-generation actions.

Can I modify the brainstorming checklist order?

No, the checklist defined in skills/brainstorming/SKILL.md (lines 22‑32) must be executed in the exact order specified. The six steps—from exploring project context to transitioning to implementation—are designed to build upon each other sequentially. Deviating from this order violates the skill's process-oriented constraints and may result in an incomplete or invalid design state.

What file format must the design document follow?

The design document must be saved to the path docs/plans/YYYY-MM-DD-<topic>-design.md, where YYYY-MM-DD represents the current date and <topic> is a descriptive slug for the design subject. According to skills/brainstorming/SKILL.md (lines 80‑84), this file must also be committed to the repository, ensuring that the approved design is persisted and version-controlled before implementation begins.

Which skill comes immediately after brainstorming?

The only permissible next skill after completing the brainstorming workflow is writing-plans. As specified in skills/brainstorming/SKILL.md (lines 55‑56) and the flow diagram, the terminal state of the brainstorming skill explicitly transitions to writing-plans. No other implementation skills may be invoked directly; attempting to call frontend-design, mcp-builder, or similar skills without this transition will trigger the hard gate constraint.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}