| name | brainstorm |
| description | Exploratory design discussion — generate and pressure-test architectural options for .NET problems before committing to a plan. Use when scope is unclear or multiple approaches exist. |
| argument-hint | <topic or problem> |
| effort | medium |
brainstorm
Interactive design exploration. Produces options, not a plan. Use
before /dotnet:plan when the problem space is ambiguous.
When to Use
- You have a goal but no clear approach ("how should we version the
API?", "should this be Blazor Server or WASM?")
- Trade-offs are non-obvious (sync vs event-driven, EF vs Dapper,
Minimal API vs Controllers)
- You want to explore 2–4 alternatives with pros/cons
Use /dotnet:plan once you've picked a direction.
Flow
- Clarify the goal and constraints in one round of Q&A
- Enumerate 2–4 options with concrete .NET implementations
- For each option: pros, cons, Iron Law alignment, complexity estimate
- Recommend one (or say "depends on X") with justification
- If user picks one, suggest
/dotnet:plan "implement option N"
Option Shape
Each option is:
### Option N: <name>
**Approach**: one-paragraph description referencing actual .NET
primitives (not vague architecture words)
**Implementation sketch**:
```csharp
// 5-15 lines showing the key call sites
Pros:
Cons:
Iron Law considerations: any that are relevant
Complexity: S / M / L
## Example Topics
- "Authentication: cookie vs JWT vs both?"
- "Background work: Hangfire vs Quartz vs hosted BackgroundService?"
- "Real-time: SignalR vs SSE vs polling?"
- "Multi-tenancy: schema-per-tenant vs row-level vs separate DBs?"
- "Migration strategy: big-bang vs strangler vs parallel run?"
## Iron Laws
Options that would violate Iron Laws are flagged, not silently
discarded — sometimes the violation is an explicit trade-off the user
accepts. But the flag must be visible.
## Output
Inline Markdown; no file written. If the user says "let's do option
3", hand off to `/dotnet:plan`.
## Integration
/dotnet:brainstorm → pick direction → /dotnet:plan → /dotnet:work
## References
- `${CLAUDE_SKILL_DIR}/references/design-heuristics.md` — when to
prefer simple vs configurable, YAGNI vs future-proofing
- `${CLAUDE_SKILL_DIR}/references/tradeoff-matrix.md` — common .NET
trade-offs (performance vs maintainability, etc.)
- `${CLAUDE_SKILL_DIR}/references/stack-choices.md` — common
library/pattern decisions with opinionated defaults
## Anti-patterns
- Single option disguised as "brainstorm" — defeats the purpose
- 10 options with no recommendation — decision fatigue
- Pure abstractions without concrete .NET primitives — users cannot
evaluate
- Brainstorming trivial problems where the answer is obvious
