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.