domains / software-engineering / pre-implementation-design / brainstorming

brainstorming

Skill card

combined

The copies overlap on the core idea of exploring intent before building, but they disagree on the procedure and contain material steps the others lack. obra/superpowers is a conversational discovery skill that explicitly allows skipping questions, uses open-ended questions, and includes visual mockups and spikes. foryourhealth111-pixel and LeoYeAI are near-identical procedural skills that require a hard gate, a fixed checklist, a design doc at a specific path, and a handoff to writing-plans. sickn33 adds mandatory non-functional requirements, an understanding lock, and a decision log. Crowning one would hide real alternatives.

Repositories

Other copies

Combined skill

---
name: brainstorming
description: "Use before any creative or implementation work to explore user intent, requirements, and design before building."
---

# Brainstorming

## Overview
Turn raw ideas into validated designs and specifications through collaborative dialogue before any implementation begins. This prevents premature implementation, hidden assumptions, and misaligned solutions.

## 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.

## Process

### 1. Explore Project Context
- Check the current project state: files, docs, recent commits, prior decisions.
- Identify what already exists vs. what is proposed.
- Note implicit constraints.

### 2. Clarify Intent (One Question at a Time)
- Ask one question per message.
- Prefer multiple-choice questions when possible; use open-ended questions when necessary.
- Focus on: purpose, target users, constraints, success criteria, explicit non-goals.
- If the user prefers to skip questions and start immediately, state any significant how-it-gets-made choice (platform, language, medium) in one plain line, then proceed to the normal workflow.

### 3. Non-Functional Requirements
Explicitly clarify or propose assumptions for:
- Performance expectations
- Scale (users, data, traffic)
- Security or privacy constraints
- Reliability / availability needs
- Maintenance and ownership expectations

### 4. Understanding Lock
Before proposing any design, provide:
- A concise summary (5-7 bullets) of what is being built, why, who it is for, key constraints, and non-goals.
- A list of all assumptions.
- A list of unresolved questions.

Ask: "Does this accurately reflect your intent? Please confirm or correct anything before we move to design."
Do NOT proceed until explicit confirmation is given.

### 5. Explore Design Approaches
- Propose 2-3 viable approaches.
- Lead with your recommended option.
- Explain trade-offs: complexity, extensibility, risk, maintenance.
- Apply YAGNI ruthlessly.

### 6. Present the Design (Incrementally)
- Break the design into sections of 200-300 words max.
- After each section, ask: "Does this look right so far?"
- Cover: architecture, components, data flow, error handling, edge cases, testing strategy.
- Offer a visual companion (mockups, diagrams, side-by-side options) whenever seeing would help more than reading.
- Offer a quick throwaway spike if it would help learn what the user wants or whether something works.

### 7. Decision Log
Maintain a running Decision Log throughout the design discussion:
- What was decided
- Alternatives considered
- Why this option was chosen

## After the Design

### Documentation
- Write the validated design to a durable, shared format (e.g., Markdown).
- Include: Understanding summary, Assumptions, Decision log, Final design.
- Save to `docs/plans/YYYY-MM-DD-<topic>-design.md` and commit to git if the project uses git.

### Implementation Handoff
- Only after documentation is complete, ask: "Ready to set up for implementation?"
- If yes, invoke the `writing-plans` skill to create a detailed implementation plan.
- Do NOT invoke any other implementation skill.

## Exit Criteria
You may exit brainstorming mode only when all of the following are true:
- Understanding Lock has been confirmed
- At least one design approach is explicitly accepted
- Major assumptions are documented
- Key risks are acknowledged
- Decision Log is complete

## Key Principles
- One question at a time
- Assumptions must be explicit
- Explore alternatives
- Validate incrementally
- Prefer clarity over cleverness
- Be willing to go back and clarify
- YAGNI ruthlessly