Code Brainstorming

Brainstorming

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by understanding the current project context, then ask questions in a numbered list to refine the idea. Once you understand what you're building, present the design and get user approval.

Hard Gate

• Do not write code.
• Do not scaffold files or projects.
• Do not take implementation action until the design brief has been presented and approved.

Workflow

1. Explore context first

• Read relevant files, docs, types, configs, and recent changes before asking intent questions.
• Follow existing patterns instead of inventing unrelated ones.
• Assess scope early. If the request spans multiple independent subsystems, say so and help decompose it before refining one slice.

2. Clarify intent

• Focus on purpose, constraints, success criteria, and boundaries the user cares about.
• Prefer concrete multiple-choice questions when they reduce ambiguity.
• Prefer open ended question other wise.
• Do not ask questions that the repository can answer.

3. Identify gray areas

• Convert the request into specific decisions that will change the design.
• Focus on behavior, interfaces, data flow, states, failure handling, and testing expectations as appropriate.
• Keep scope fixed. If the user suggests a new capability, mark it as deferred and return to the current change.

4. Compare approaches

• Present 2-3 viable approaches.
• Lead with the recommended option.
• Explain tradeoffs in terms of codebase fit, complexity, flexibility, and user goals.

Key Principles

• Multiple choice preferred - Easier to answer than open-ended when possible
• YAGNI ruthlessly - Remove unnecessary features from all designs
• Explore alternatives - Propose 2-3 approaches before settling
• Incremental validation - Present design, get approval before moving on
• Be flexible - Go back and clarify when something doesn't make sense
• Question - Call out assumptions explicitly