# Brainstorming

> Turn vague ideas into a validated design/spec through structured brainstorming. Use before any creative work (new features, UI/components, behavior changes, refactors) and whenever a user asks to brainstorm, define requirements, propose approaches, or write a design doc. Use when this capability is needed.

- Skill: `tomevault-io/brainstorming-15` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/brainstorming-15`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/brainstorming-15/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/brainstorming-15

---


# Brainstorming Ideas Into Designs

## Overview

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

Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200–300 words), checking after each section whether it looks right so far.

## The Process

**Understanding the idea:**
- Review current project context first (key files/docs, recent commits, existing patterns).
- Ask one question per message to refine the idea (prefer multiple-choice when possible).
- Focus on: purpose, constraints, success criteria, non-goals.

**Exploring approaches:**
- Propose 2–3 approaches with trade-offs.
- Recommend one approach and explain why.

**Presenting the design:**
- Present the design in 200–300 word chunks and confirm after each chunk.
- Cover: architecture, components, data flow, error handling, testing.
- Be ready to backtrack if the user says something doesn’t fit.

## After the Design

**Documentation:**
- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md` when that convention exists; otherwise create `docs/plans/` or ask where to put it.
- If you have a writing-quality skill available, use it before finalizing the doc.
- If the repo is under git and the user wants it tracked, commit the design doc.

**Implementation (if continuing):**
- Ask: “Ready to set up for implementation?”
- If the user wants a separate workspace, use a git worktree.
- Create a concrete implementation plan before writing code.

## Key Principles

- **One question at a time** — Don’t overwhelm with a questionnaire.
- **Multiple choice preferred** — Faster to answer and reduces ambiguity.
- **YAGNI ruthlessly** — Remove unnecessary scope/features from designs.
- **Explore alternatives** — Always consider 2–3 viable approaches.
- **Incremental validation** — Confirm each design chunk before continuing.
- **Be flexible** — Adjust quickly when something doesn’t fit.

---
> Converted and distributed by [TomeVault](https://tomevault.io/claim/okwinds) — claim your Tome and manage your conversions.
<!-- tomevault:4.0:skill_md:2026-04-11 -->