# Brainstorming

> Structured design facilitation for new features, algorithms, or architecture decisions. Use before any significant implementation work, when exploring trade-offs, or when the user has a vague idea that needs to be refined into a concrete plan.

- Skill: `majiayu000/brainstorming-44` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/brainstorming-44`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/brainstorming-44/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/brainstorming-44

---


# Brainstorming Ideas Into Designs

## Purpose

Turn raw ideas into **clear, validated designs** through structured dialogue **before any implementation begins**. Prevent premature coding, hidden assumptions, and misaligned solutions.

**You must NOT implement, code, or modify files while this skill is active.**

## Process

### 1. Understand Current Context

Before asking questions:
- Review the current project state (files, docs, prior decisions)
- Identify what already exists vs. what is proposed
- Note implicit constraints

### 2. Clarify the Idea (One Question at a Time)

- Ask **one question per message**
- Prefer **multiple-choice questions** when possible
- Focus on: purpose, constraints, success criteria, and explicit non-goals
- For algorithms/math: clarify accuracy requirements, edge cases, expected inputs

### 3. Technical Requirements

Explicitly clarify or propose assumptions for:
- **Performance**: allocation budget, runtime targets, real-time constraints
- **Accuracy**: numerical precision, validation references (papers, test cases)
- **Differentiability**: which AD backends must work, what needs to be differentiable
- **Composability**: how it integrates with existing types and interfaces
- **Scope**: what is explicitly out of scope

If the user is unsure, propose reasonable defaults and mark them as **assumptions**.

### 4. Understanding Lock (Hard Gate)

Before proposing any design, provide a summary covering:
- What is being built and why
- Key constraints and non-goals
- All assumptions listed explicitly

Ask: *"Does this accurately reflect your intent? Confirm or correct before we move to design."*

**Do NOT proceed until confirmed.**

### 5. Explore Approaches

- Propose **2-3 viable approaches** with trade-offs
- Lead with recommended option
- Compare on: complexity, performance, extensibility, AD compatibility, maintenance
- Apply YAGNI -- avoid speculative features

### 6. Present the Design Incrementally

- Break into sections of 200-300 words max
- After each section ask: *"Does this look right so far?"*
- Cover as relevant: type hierarchy, API surface, data flow, error handling, edge cases, testing strategy

### 7. Decision Log

Maintain a running log: what was decided, alternatives considered, and why.

## After the Design

Once validated:
- Write the final design to a Markdown document
- Include: summary, assumptions, decision log, final design
- Only then ask: *"Ready to proceed to implementation?"*

## Exit Criteria

All must be true before exiting brainstorming:
- Understanding lock confirmed
- At least one approach explicitly accepted
- Assumptions documented
- Key risks acknowledged
- Decision log complete