# Code Brainstorming

> Turn coding ideas into approved designs and planning-ready implementation briefs before coding starts. Use for new features, meaningful behavior changes, ambiguous implementation requests, refactors that change system shape, or early architecture and design discussions. Do not use for tiny obvious edits, isolated typo fixes, trivial null checks, or other straightforward bug fixes that do not need design work.

- Skill: `rileycornelius/code-brainstorming` (Agent Skill)
- Install (CLI): `npx skillmds@latest add rileycornelius/code-brainstorming`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rileycornelius/code-brainstorming/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: RileyCornelius (https://skillmd.com/u/rileycornelius)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rileycornelius/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