Brainstorm

---
name: brainstorming
description:
  "You MUST use this before any creative work - creating features, building
  components, adding functionality, or modifying behavior. Explores user intent,
  requirements and design before implementation."
---

# Brainstorming Ideas Into Designs

## Overview

Help turn ideas into fully formed designs and specs through natural
collaborative dialogue.

Start by understanding the current project context, then ask questions one at a
time to refine the idea. Once you understand what you're building, present the
design in small sections (200-300 words), checking after each section whether it
looks right so far.

## The Process

**Understanding the idea:**

**Note**: This skill is typically invoked by agents like nimbus-researcher when
requirements are unclear. You can also invoke it directly when:

- Starting a new component and need to explore design options
- Facing architectural decisions with multiple valid approaches
- Requirements are ambiguous and need clarification

For complete component creation with OpenSpec integration, use
`/propose-component` command instead.

- You SHOULD begin by reviewing the current project state (files, docs, recent
  commits). This ensures the design fits existing patterns and doesn't duplicate
  work.
- You SHOULD ask questions one at a time to refine the idea. This creates a
  focused conversation and helps clarify requirements incrementally.
- You MAY prefer multiple choice questions when they clarify options quickly,
  but open-ended questions are fine too—choose based on conversation flow.
- You SHOULD structure exploration into separate messages if multiple topics
  need investigation. This prevents overwhelming both parties.
- You MUST focus on understanding: purpose, constraints, and success criteria.

**Exploring approaches:**

- You SHOULD propose 2-3 different approaches with trade-offs. This explores the
  design space and prevents premature convergence on the first idea.
- You SHOULD present options conversationally with your recommendation and
  reasoning. Explain why you're recommending one approach over others.
- You MUST lead with your RECOMMENDED option and explain the trade-offs. Help
  the user understand your reasoning before they decide.

**Presenting the design:**

- You SHOULD verify you understand the full scope before presenting (not just
  your initial interpretation). Ask clarifying questions until you can describe
  what's being built with confidence.
- You MUST present design in reviewable sections (200-300 words each). This lets
  the user verify direction incrementally rather than discovering misalignment
  at the end.
- You MUST ask after each section whether it looks right so far. If it doesn't,
  correct the misalignment before moving forward.
- You MUST cover: architecture, components, data flow, error handling, and
  testing. Missing any of these creates gaps later.
- You SHOULD be ready to go back and clarify if something doesn't make sense.
  This is normal and expected.

## After the Design

**Next Steps:**

- You have a validated design/plan document
- User can choose their next step:
  - Create an OpenSpec proposal via `/openspec:proposal` for formal
    specification
  - Use the plan for implementation planning
  - Continue refining the design if needed
  - Save the plan for later reference
- Ask the user what they'd like to do next

## Key Principles

- **YAGNI ruthlessly**: You MUST remove unnecessary features from all designs.
  Scope creep at design time is easier to fix than during implementation.

- **Explore alternatives**: You SHOULD propose 2-3 approaches with trade-offs
  before settling on the recommended approach. This prevents the "first idea"
  bias and helps users understand the design space.

- **Incremental validation**: You MUST present design in sections and ask after
  each one. Discovering fundamental misalignment after 30 minutes of work is
  wasteful.

- **Be flexible with clarification**: You SHOULD be ready to go back and ask
  clarifying questions when something doesn't make sense. This is normal and
  expected, not a failure.

- **Focus on patterns**: You MUST ensure designs align with established Nimbus
  patterns and standards (see ./openspec/AGENTS.md for project architecture).
  Consistency reduces learning curve for implementers.