gracefullight Brainstorm - Design-First Ideation
When to use
- Exploring a new feature idea before planning
- Understanding user intent and constraints before committing to an approach
- Comparing multiple design approaches with trade-offs
- When the user says "I have an idea" or "let's design something"
- Before invoking
/planfor complex or ambiguous requests
When NOT to use
- Requirements are already clear and well-defined -> use pm-agent directly
- Implementing actual code -> delegate to specialized agents
- Performing code reviews -> use QA Agent
- Debugging existing issues -> use debug-agent
Core Rules
- No implementation or planning before design approval - brainstorm produces a design document, not code or task plans
- One question at a time - ask clarifying questions sequentially, not in batches
- Always propose 2-3 approaches - include a recommended option with trade-off analysis
- Section-by-section design - present design incrementally with user confirmation at each step
- YAGNI - do not over-engineer; design only what is needed for the stated goal
- Save design, then transition - persist the approved design document before handing off to
/plan
How to Execute
Follow the brainstorm workflow step by step:
- Phase 1 - Context: Explore the existing codebase and understand the project landscape
- Phase 2 - Questions: Ask clarifying questions one at a time to understand intent and constraints
- Phase 3 - Approaches: Propose 2-3 approaches with a recommended option and trade-off matrix
- Phase 4 - Design: Present the detailed design section by section, getting user approval at each step
- Phase 5 - Documentation: Save the approved design to
docs/plans/and project memory - Phase 6 - Transition: Hand off to
/planfor task decomposition
Common Pitfalls
- Jumping to solutions: Asking "how" before fully understanding "what" and "why"
- Too many questions at once: Overwhelming the user with a wall of questions
- Single approach bias: Presenting only one option without alternatives
- Over-engineering: Designing for hypothetical future requirements instead of stated needs
- Skipping confirmation: Moving forward without explicit user approval on design decisions
Execution Protocol (CLI Mode)
Vendor-specific execution protocols are injected automatically by oma agent:spawn.
Source files live under ../_shared/runtime/execution-protocols/{vendor}.md.
References
- Context loading:
../_shared/core/context-loading.md - Reasoning templates:
../_shared/core/reasoning-templates.md - Clarification protocol:
../_shared/core/clarification-protocol.md - Quality principles:
../_shared/core/quality-principles.md - Skill-to-agent mapping:
../_shared/core/skill-routing.md