Brainstorming Complex Feature
Collaborative workflow for transforming vague ideas into well-defined features through structured dialogue before specification.
For well-defined requirements, skip brainstorming and use Spec-Driven Development directly.
When to Use
Unclear or incomplete requirements that need refinement
Exploring multiple approaches before committing to a direction
New features where you know the goal but not the implementation
Stakeholder alignment needed before detailed planning
Plugins needed for this workflow
FPF (optional, for systematic hypothesis evaluation)
Workflow
How It Works
1. Brainstorm the idea
Use the /sdd:brainstorm command to start a collaborative dialogue. The LLM will explore your project context and ask clarifying questions one at a time.
After starting, the LLM will:
Review your project structure, docs, and recent commits
Ask focused questions (preferring multiple choice when possible)
Help you define purpose, constraints, and success criteria
Answer each question to progressively refine the idea. The conversation continues until requirements are clear.
2. Explore approaches
Once the LLM understands your needs, it will propose 2-3 different approaches with trade-offs.
After reviewing options, select your preferred approach or ask for more exploration. The LLM leads with its recommendation and explains the reasoning.
Using FPF for Systematic Evaluation
For architectural decisions with long-term consequences, consider using the FPF plugin to systematically evaluate approaches:
FPF provides:
Structured hypothesis generation - Multiple competing options with diverse perspectives
Logical verification - Check each option against project constraints
Evidence validation - Empirical testing with trust scores
Auditable decisions - Full reasoning trail preserved in
.fpf/directory
When to use FPF vs SDD brainstorming:
Architectural decisions with long-term impact
Yes
No
Multiple viable approaches needing systematic comparison
Yes
Maybe
Decisions requiring audit trails
Yes
No
Quick exploration of ideas
No
Yes
Easily reversible decisions
No
Yes
Time-critical situations
No
Yes
See FPF plugin documentation for detailed workflow steps.
3. Present design
The LLM presents the validated approach as a design document in 200-300 word sections, checking after each section whether it looks right.
After each section, confirm it matches your expectations or request changes. Once complete, the design is saved to docs/plans/YYYY-MM-DD-<topic>-design.md.
4. Create task and plan specification
Use the /sdd:add-task command to create a task file from the refined design, then /sdd:plan to generate a detailed specification with architecture, implementation steps, and verification criteria.
After LLM completes, review the task file in .specs/tasks/draft/. You can adjust the task file to incorporate additional details from the brainstorming session.
Then run planning to generate the full specification:
After LLM completes, review the refined specification in .specs/tasks/todo/. The plan includes architecture design, implementation steps with parallelization, and verification rubrics. You can adjust and run /sdd:plan --refine to iterate.
5. Implement features
Use the /sdd:implement command to execute the implementation. This produces working code with tests and verification.
During implementation, the LLM executes each step with quality gates, writes tests, and verifies the solution works as expected. More info in Spec-Driven Development workflow.
6. Review and ship
Complete the workflow with code review and pull request creation.
After completion, your feature is ready for merge.
Key Principles
The brainstorming phase follows these principles to ensure productive refinement:
One question at a time - Focused dialogue prevents overwhelm
Multiple choice preferred - Easier to answer than open-ended questions
YAGNI ruthlessly - Remove unnecessary features from designs
Explore alternatives - Always consider 2-3 approaches before committing
Incremental validation - Present design in sections, validate each one
Last updated