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
1---2name: brainstorming-443description: 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.4---5
6# Brainstorming Ideas Into Designs
7
8## Purpose
9
10Turn raw ideas into **clear, validated designs** through structured dialogue **before any implementation begins**. Prevent premature coding, hidden assumptions, and misaligned solutions.
11
12**You must NOT implement, code, or modify files while this skill is active.**
13
14## Process
15
16### 1. Understand Current Context
17
18Before asking questions:
19- Review the current project state (files, docs, prior decisions)
20- Identify what already exists vs. what is proposed
21- Note implicit constraints
22
23### 2. Clarify the Idea (One Question at a Time)
24
25- Ask **one question per message**
26- Prefer **multiple-choice questions** when possible
27- Focus on: purpose, constraints, success criteria, and explicit non-goals
28- For algorithms/math: clarify accuracy requirements, edge cases, expected inputs
29
30### 3. Technical Requirements
31
32Explicitly clarify or propose assumptions for:
33- **Performance**: allocation budget, runtime targets, real-time constraints
34- **Accuracy**: numerical precision, validation references (papers, test cases)
35- **Differentiability**: which AD backends must work, what needs to be differentiable
36- **Composability**: how it integrates with existing types and interfaces
37- **Scope**: what is explicitly out of scope
38
39If the user is unsure, propose reasonable defaults and mark them as **assumptions**.
40
41### 4. Understanding Lock (Hard Gate)
42
43Before proposing any design, provide a summary covering:
44- What is being built and why
45- Key constraints and non-goals
46- All assumptions listed explicitly
47
48Ask: *"Does this accurately reflect your intent? Confirm or correct before we move to design."*
49
50**Do NOT proceed until confirmed.**
51
52### 5. Explore Approaches
53
54- Propose **2-3 viable approaches** with trade-offs
55- Lead with recommended option
56- Compare on: complexity, performance, extensibility, AD compatibility, maintenance
57- Apply YAGNI -- avoid speculative features
58
59### 6. Present the Design Incrementally
60
61- Break into sections of 200-300 words max
62- After each section ask: *"Does this look right so far?"*
63- Cover as relevant: type hierarchy, API surface, data flow, error handling, edge cases, testing strategy
64
65### 7. Decision Log
66
67Maintain a running log: what was decided, alternatives considered, and why.
68
69## After the Design
70
71Once validated:
72- Write the final design to a Markdown document
73- Include: summary, assumptions, decision log, final design
74- Only then ask: *"Ready to proceed to implementation?"*
75
76## Exit Criteria
77
78All must be true before exiting brainstorming:
79- Understanding lock confirmed
80- At least one approach explicitly accepted
81- Assumptions documented
82- Key risks acknowledged
83- Decision log complete
majiayu000