# Understanding the Constraints of the Brainstorming Skill in Superpowers > Explore the six strict constraints of the brainstorming skill in Superpowers. Learn how the pre-condition, gate, checklist, and terminal state prevent implementation until design approval. - Repository: [Jesse Vincent/superpowers](https://github.com/obra/superpowers) - Tags: deep-dive - Published: 2026-02-16 --- **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`](https://github.com/obra/superpowers/blob/main/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`](https://github.com/obra/superpowers/blob/main/commands/brainstorm.md) (lines 2‑3), the description explicitly states: "You MUST use this before any creative work." ```yaml # 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 `` block in [`skills/brainstorming/SKILL.md`](https://github.com/obra/superpowers/blob/main/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. ```yaml # skills/brainstorming/SKILL.md Do NOT invoke any implementation skill … until you have presented a design and the user has approved it. ``` ### 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`](https://github.com/obra/superpowers/blob/main/skills/brainstorming/SKILL.md) (lines 22‑32), the checklist mandates specific actions ranging from context exploration to skill transition. ```yaml ## 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`](https://github.com/obra/superpowers/blob/main/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. ```dot 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`](https://github.com/obra/superpowers/blob/main/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`](https://github.com/obra/superpowers/blob/main/skills/brainstorming/SKILL.md) (lines 80‑84), the design document must be saved to `docs/plans/YYYY-MM-DD--design.md` and committed to the repository. ```yaml # (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`](https://github.com/obra/superpowers/blob/main/skills/brainstorming/SKILL.md)**: Contains the full skill definition, including the `` block, ordered checklist, flow diagram, and documentation requirements. - **[`commands/brainstorm.md`](https://github.com/obra/superpowers/blob/main/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--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 `` block in [`skills/brainstorming/SKILL.md`](https://github.com/obra/superpowers/blob/main/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`](https://github.com/obra/superpowers/blob/main/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--design.md`, where `YYYY-MM-DD` represents the current date and `` is a descriptive slug for the design subject. According to [`skills/brainstorming/SKILL.md`](https://github.com/obra/superpowers/blob/main/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`](https://github.com/obra/superpowers/blob/main/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.