Simple Brainstorm
A structured yet lightweight brainstorming skill designed to move from idea to actionable direction quickly. It preserves the rigor of collaborative design — exploring intent, evaluating trade-offs, and validating decisions — while eliminating process overhead that doesn't scale to small and medium tasks.
The goal is simple: understand what the user wants, think through the options together, pick a direction, and get moving. No multi-phase rituals, no mandatory design documents, no endless rounds of clarification. Just enough structure to make good decisions, and nothing more.
Ground Rules
Do NOT write any code, scaffold any files, or take any implementation action until the user has explicitly approved a direction. This applies even when the task seems obvious. The whole point of brainstorming is to pause and think before building. Respect that boundary.
Process Flow
digraph simple_brainstorm {
rankdir=TB
node [shape=box style=rounded]
Discover -> Propose
Propose -> Converge
Converge -> Approved [label="yes"]
Converge -> Propose [label="no (max 2x)"]
Approved [shape=diamond]
Approved -> Capture
Capture -> Implement
}
Discover — Assess project context — codebase, conventions, existing patterns. Ask up to 3 focused questions (prefer multiple-choice) to clarify intent, constraints, and success criteria. Batch related questions together. If the request is already clear, skip straight to proposing.
Propose — Present 2 approaches with trade-offs. Lead with your recommendation and say why. Keep each option to a short paragraph. Scale detail to the task — a few sentences for simple work, more reasoning for complex decisions.
Converge — Get explicit user approval. If rejected, revise and repropose — max 2 rounds. If still not aligned, ask the user to state what they want directly. A good-enough direction chosen quickly beats a perfect one chosen slowly.
Capture — Record the chosen direction (what, why, key decisions) as an inline comment in the first file you create, or share it in chat. No separate design doc unless the user asks for one.
Principles
Speed over ceremony — The value of brainstorming is in the thinking, not in the artifacts it produces. Skip formality wherever it doesn't add real value. A quick conversation that leads to a good decision is better than a polished document that delays one.
YAGNI — Design only for what's needed right now. Don't introduce abstractions, extension points, or flexibility for requirements that don't exist yet. If they come up later, you can handle them then. Speculative design creates more problems than it solves.
Bias toward action — When two options are close in quality, just pick one and go. Spending extra time trying to find the theoretically optimal choice almost never pays off. Movement creates clarity. You'll learn more from building than from deliberating.
Batched discovery — Ask your clarifying questions together, not one at a time across multiple messages. Drawn-out discovery wastes the user's time and breaks their flow. Get what you need in one round and move forward.
Proportional depth — Match the weight of the process to the weight of the task. A small bug fix or config change might go through steps 1 and 2 in a single message. A new subsystem deserves a more thorough exploration in step 2. Let the complexity of the work guide the complexity of the conversation.
1---2name: simple-brainstorm3description: Invoke before any creative or architectural work — feature design, component creation, or behavioral changes. A streamlined brainstorming process optimized for fast, focused decision-making.4---5# Simple Brainstorm67A structured yet lightweight brainstorming skill designed to move from idea to actionable direction quickly. It preserves the rigor of collaborative design — exploring intent, evaluating trade-offs, and validating decisions — while eliminating process overhead that doesn't scale to small and medium tasks.89The goal is simple: understand what the user wants, think through the options together, pick a direction, and get moving. No multi-phase rituals, no mandatory design documents, no endless rounds of clarification. Just enough structure to make good decisions, and nothing more.1011## Ground Rules1213Do NOT write any code, scaffold any files, or take any implementation action until the user has explicitly approved a direction. This applies even when the task seems obvious. The whole point of brainstorming is to pause and think before building. Respect that boundary.1415## Process Flow1617```dot18digraph simple_brainstorm {19 rankdir=TB20 node [shape=box style=rounded]2122 Discover -> Propose23 Propose -> Converge24 Converge -> Approved [label="yes"]25 Converge -> Propose [label="no (max 2x)"]26 Approved [shape=diamond]27 Approved -> Capture28 Capture -> Implement29}30```3132- **Discover** — Assess project context — codebase, conventions, existing patterns. Ask up to 3 focused questions (prefer multiple-choice) to clarify intent, constraints, and success criteria. Batch related questions together. If the request is already clear, skip straight to proposing.3334- **Propose** — Present 2 approaches with trade-offs. Lead with your recommendation and say why. Keep each option to a short paragraph. Scale detail to the task — a few sentences for simple work, more reasoning for complex decisions.3536- **Converge** — Get explicit user approval. If rejected, revise and repropose — max 2 rounds. If still not aligned, ask the user to state what they want directly. A good-enough direction chosen quickly beats a perfect one chosen slowly.3738- **Capture** — Record the chosen direction (what, why, key decisions) as an inline comment in the first file you create, or share it in chat. No separate design doc unless the user asks for one.3940## Principles4142- **Speed over ceremony** — The value of brainstorming is in the thinking, not in the artifacts it produces. Skip formality wherever it doesn't add real value. A quick conversation that leads to a good decision is better than a polished document that delays one.4344- **YAGNI** — Design only for what's needed right now. Don't introduce abstractions, extension points, or flexibility for requirements that don't exist yet. If they come up later, you can handle them then. Speculative design creates more problems than it solves.4546- **Bias toward action** — When two options are close in quality, just pick one and go. Spending extra time trying to find the theoretically optimal choice almost never pays off. Movement creates clarity. You'll learn more from building than from deliberating.4748- **Batched discovery** — Ask your clarifying questions together, not one at a time across multiple messages. Drawn-out discovery wastes the user's time and breaks their flow. Get what you need in one round and move forward.4950- **Proportional depth** — Match the weight of the process to the weight of the task. A small bug fix or config change might go through steps 1 and 2 in a single message. A new subsystem deserves a more thorough exploration in step 2. Let the complexity of the work guide the complexity of the conversation.
aiskillstore