brainstorm

Name: brainstorm
Author: NeoLabHQ

914installs132forks

How to install brainstorm?

neolabhq/context-engineering-kit/brainstorm

$npx -y skills add NeoLabHQ/context-engineering-kit --skill brainstorm

Installs into the current project.

Summary

Use when creating or developing, before writing code or implementation plans - refines rough ideas into fully-formed designs through collaborative questioning, alternative exploration, and incremental validation. Don't use during clear 'mechanical' processes

Files · 1

View on GitHub

SKILL.md

1	# Brainstorming Ideas Into Designs
2
3	## Overview
4
5	Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
6
7	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.
8
9	## The Process
10
11	Understanding the idea:
12
13	- Check out the current project state first (files, docs, recent commits)
14	- Ask questions one at a time to refine the idea
15	- Prefer multiple choice questions when possible, but open-ended is fine too
16	- Only one question per message - if a topic needs more exploration, break it into multiple questions
17	- Focus on understanding: purpose, constraints, success criteria
18
19	Exploring approaches:
20
21	- Generate 6 possible approaches with trade-offs. Approaches should each include a text and a numeric probability. Please sample responses at random from the [full distribution / tails of the distribution], in such way that:
22	- For first 3 responses aim for high probability, over 0.80
23	- For last 3 responses aim for diversity - explore different regions of the solution space, such that the probability of each response is less than 0.10
24	- Present options conversationally with your recommendation and reasoning
25	- Lead with your recommended option and explain why
26
27	Presenting the design:
28
29	- Once you believe you understand what you're building, present the design
30	- Break it into sections of 200-300 words
31	- Ask after each section whether it looks right so far
32	- Cover: architecture, components, data flow, error handling, testing
33	- Be ready to go back and clarify if something doesn't make sense
34
35	## After the Design
36
37	if user provided draft specification file, then update it directly, if not then use `/add-task` skill to create task file for target approach
38
39	Important: In specification file, write target approach in sections, in `## Initial User Prompt -> ### Requirements` section, before `## Description` section. Description will be filled in future stage.
40
41	After filling task file, suggest use to run `/clear` and then `/plan-task <task-file-path>` to refine the task file.
42
43	## Key Principles
44
45	- One question at a time - Don't overwhelm with multiple questions
46	- Multiple choice preferred - Easier to answer than open-ended when possible
47	- YAGNI ruthlessly - Remove unnecessary features from all designs
48	- Explore alternatives - Always propose 2-3 approaches before settling
49	- Incremental validation - Present design in sections, validate each
50	- Be flexible - Go back and clarify when something doesn't make sense

People who liked this also viewed

6 picks

Type

brainstorm

914installs132forks

View on GitHub

How to install brainstorm?

neolabhq/context-engineering-kit/brainstorm

$npx -y skills add NeoLabHQ/context-engineering-kit --skill brainstorm

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Brainstorming Ideas Into Designs
2
3	## Overview
4
5	Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
6
7	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.
8
9	## The Process
10
11	Understanding the idea:
12
13	- Check out the current project state first (files, docs, recent commits)
14	- Ask questions one at a time to refine the idea
15	- Prefer multiple choice questions when possible, but open-ended is fine too
16	- Only one question per message - if a topic needs more exploration, break it into multiple questions
17	- Focus on understanding: purpose, constraints, success criteria
18
19	Exploring approaches:
20
21	- Generate 6 possible approaches with trade-offs. Approaches should each include a text and a numeric probability. Please sample responses at random from the [full distribution / tails of the distribution], in such way that:
22	- For first 3 responses aim for high probability, over 0.80
23	- For last 3 responses aim for diversity - explore different regions of the solution space, such that the probability of each response is less than 0.10
24	- Present options conversationally with your recommendation and reasoning
25	- Lead with your recommended option and explain why
26
27	Presenting the design:
28
29	- Once you believe you understand what you're building, present the design
30	- Break it into sections of 200-300 words
31	- Ask after each section whether it looks right so far
32	- Cover: architecture, components, data flow, error handling, testing
33	- Be ready to go back and clarify if something doesn't make sense
34
35	## After the Design
36
37	if user provided draft specification file, then update it directly, if not then use `/add-task` skill to create task file for target approach
38
39	Important: In specification file, write target approach in sections, in `## Initial User Prompt -> ### Requirements` section, before `## Description` section. Description will be filled in future stage.
40
41	After filling task file, suggest use to run `/clear` and then `/plan-task <task-file-path>` to refine the task file.
42
43	## Key Principles
44
45	- One question at a time - Don't overwhelm with multiple questions
46	- Multiple choice preferred - Easier to answer than open-ended when possible
47	- YAGNI ruthlessly - Remove unnecessary features from all designs
48	- Explore alternatives - Always propose 2-3 approaches before settling
49	- Incremental validation - Present design in sections, validate each
50	- Be flexible - Go back and clarify when something doesn't make sense

People who liked this also viewed

6 picks

Type