22 lines
1.2 KiB
Markdown
22 lines
1.2 KiB
Markdown
---
|
||
description: Generate 3–5 design alternatives with trade-offs before committing to an approach
|
||
argument-hint: "[problem or feature to design]"
|
||
subagent: true
|
||
fork: true
|
||
---
|
||
Brainstorm approaches for: $@
|
||
|
||
Structure your answer as:
|
||
1. **Problem restatement** — one paragraph; what we're solving, what constraints matter, what "done" looks like
|
||
2. **Alternatives** — 3 to 5 distinct approaches. For each:
|
||
- **Summary** — one or two sentences
|
||
- **How it works** — the key mechanism
|
||
- **Pros** — what it gets right
|
||
- **Cons** — what it costs, risks, or breaks
|
||
- **Best when** — the conditions that would make this the right pick
|
||
3. **Comparison table** — across the alternatives, score or rank on: complexity, time-to-ship, reversibility, performance, fit-with-existing-code
|
||
4. **Recommendation** — which one to pick *given the current codebase*, with the second choice as a fallback
|
||
5. **Unknowns** — questions that, if answered, would change the recommendation
|
||
|
||
Be opinionated. Surface real trade-offs, not strawmen. If the obvious approach wins decisively, say so and only enumerate 2 alternatives — don't manufacture options for the sake of a full set. If the problem is under-specified, ask clarifying questions before brainstorming.
|