Brainstorm Design
Turn an unclear idea into an implementation-ready direction before code changes begin.
Core Rules
- Inspect local context before asking: relevant README, AGENTS.md, code, tests, and recent changes.
- Do not write code during brainstorming unless the user explicitly switches to implementation.
- Lead with a recommendation, not a neutral menu.
- Prefer "simple now, extensible later"; flag speculative abstractions.
Clarifying Questions
- Ask before presenting options if decision-critical details are missing, contradictory, or unclear.
- Do not proceed on assumptions that affect scope, target behavior, safety, data, API, UX, or acceptance criteria.
- Ask numbered questions with lettered options; option A must be recommended. Continue until the design can be chosen without decision-critical assumptions.
Do Not Trigger
- Direct low-risk edits with clear acceptance criteria.
- Ordinary code explanation without design alternatives.
- Concrete failures or stack traces.
- Already-approved plan execution.
Workflow
Clarify the goal.
- Restate the concrete outcome.
- Identify success criteria, constraints, affected users, and failure modes.
- Ask when missing context affects the recommendation.
Gather evidence.
- Search for existing patterns before inventing new ones.
- Read only the files needed to understand the area.
- Note conventions, integration points, dependencies, and tests.
Compare options.
- Present 2-3 materially different approaches only when tradeoffs matter.
- Put the recommended approach first.
- Include a smallest-useful option when scope looks inflated.
- If evidence makes the direction obvious, do not invent alternatives.
Recommend the next action.
- Plan substantial work.
- Implement small clear work only after the direction is agreed or evidence fully resolves it.
- Stress-test risky claims before committing to them.
Output
Use the smallest output that preserves evidence, decision, and next action.
**Context**
[Relevant code/docs evidence.]
**Options**
1. [Recommended]: [tradeoff]
2. [Alternative]: [tradeoff]
3. [Smallest useful version]: [tradeoff]
**Recommendation**
[Concrete direction and why.]
**Next Step**
[Ask, plan, implement, investigate, or stop.]
For non-trivial decisions, include the rejected alternatives, key risk, and validation required.
Quality Bar
- Ground recommendations in codebase facts, not generic architecture advice.
- Separate hard requirements from preferences.
- Do not over-design for hypothetical future features.
1---2name: brainstorm-design3description: Collaborative design workflow for significant software changes: new features, architecture decisions, refactors, migrations, and ambiguous code implementation requests. Use before writing code when the right technical solution is unclear, risk is non-trivial, or multiple codebase-compatible approaches exist.4---56# Brainstorm Design78Turn an unclear idea into an implementation-ready direction before code changes begin.910## Core Rules1112- Inspect local context before asking: relevant README, AGENTS.md, code, tests, and recent changes.13- Do not write code during brainstorming unless the user explicitly switches to implementation.14- Lead with a recommendation, not a neutral menu.15- Prefer "simple now, extensible later"; flag speculative abstractions.1617## Clarifying Questions1819- Ask before presenting options if decision-critical details are missing, contradictory, or unclear.20- Do not proceed on assumptions that affect scope, target behavior, safety, data, API, UX, or acceptance criteria.21- Ask numbered questions with lettered options; option A must be recommended. Continue until the design can be chosen without decision-critical assumptions.2223## Do Not Trigger2425- Direct low-risk edits with clear acceptance criteria.26- Ordinary code explanation without design alternatives.27- Concrete failures or stack traces.28- Already-approved plan execution.2930## Workflow31321. Clarify the goal.33 - Restate the concrete outcome.34 - Identify success criteria, constraints, affected users, and failure modes.35 - Ask when missing context affects the recommendation.36372. Gather evidence.38 - Search for existing patterns before inventing new ones.39 - Read only the files needed to understand the area.40 - Note conventions, integration points, dependencies, and tests.41423. Compare options.43 - Present 2-3 materially different approaches only when tradeoffs matter.44 - Put the recommended approach first.45 - Include a smallest-useful option when scope looks inflated.46 - If evidence makes the direction obvious, do not invent alternatives.47484. Recommend the next action.49 - Plan substantial work.50 - Implement small clear work only after the direction is agreed or evidence fully resolves it.51 - Stress-test risky claims before committing to them.5253## Output5455Use the smallest output that preserves evidence, decision, and next action.5657```markdown58**Context**59[Relevant code/docs evidence.]6061**Options**621. [Recommended]: [tradeoff]632. [Alternative]: [tradeoff]643. [Smallest useful version]: [tradeoff]6566**Recommendation**67[Concrete direction and why.]6869**Next Step**70[Ask, plan, implement, investigate, or stop.]71```7273For non-trivial decisions, include the rejected alternatives, key risk, and validation required.7475## Quality Bar7677- Ground recommendations in codebase facts, not generic architecture advice.78- Separate hard requirements from preferences.79- Do not over-design for hypothetical future features.
gslava