brainstorming

Name: brainstorming
Author: krzysztofsurdy

18installs1forks

How to install brainstorming?

krzysztofsurdy/code-virtuoso/brainstorming

$npx -y skills add krzysztofsurdy/code-virtuoso --skill brainstorming

Installs into the current project.

Summary

Interactive pre-implementation design exploration. Use when the user has a vague idea, feature request, or problem statement but no written spec. Asks focused questions one at a time to surface goals, non-goals, constraints, success criteria, and risks, then produces a written sp

Files · 1

View on GitHub

SKILL.md

1	# Brainstorming
2
3	Structured pre-implementation design exploration. Transforms a vague idea into a written spec through focused, one-at-a-time questioning before any code is written, any plan is created, or any architecture is decided. The spec is the deliverable - everything else follows from it.
4
5	No code until the spec is written and approved.
6
7	## When to Use
8
9	- The user says "I want to build X" but has no written requirements
10	- A feature request exists as a sentence or two with no detail
11	- The user asks "how should I build X" before defining what X actually is
12	- Someone says "let's brainstorm" or "help me figure this out"
13	- A problem statement exists but the solution space is unexplored
14
15	## Quick Start
16
17	```
18	/brainstorming user authentication for a SaaS app
19	/brainstorming migrate our monolith to services
20	/brainstorming # asks what to explore
21	```
22
23	If `$ARGUMENTS` is provided, use it as the initial topic and skip straight to Phase 1. If no argument, ask: "What idea, feature, or problem would you like to explore?"
24
25	---
26
27	## Workflow
28
29	This skill uses guided phases - each phase is a separate file loaded one at a time. Every phase ends with a gate where you must wait for user confirmation before proceeding. Do not skip phases or merge them.
30
31	\| Phase \| File \| What it covers \|
32	\|---\|---\|---\|
33	\| 1 \| [Intake](phases/01-intake.md) \| Read context, classify maturity, summarize understanding \|
34	\| 2 \| [Divergence](phases/02-divergence.md) \| Expand problem space with one-at-a-time questions across 7 categories \|
35	\| 3 \| [Convergence](phases/03-convergence.md) \| Narrow to concrete scope, lock must-haves and non-goals \|
36	\| 4 \| [Spec Writing](phases/04-spec-writing.md) \| Write full spec from gathered material, run quality checklist \|
37	\| 5 \| [Approval](phases/05-approval.md) \| Get explicit user approval, hard-gate implementation \|
38
39	Start by loading Phase 1. After the user confirms each phase, load the next. Never load multiple phases at once. Never skip a phase.
40
41	---
42
43	## Critical Rules
44
45	1. No code until the spec is approved. Not pseudocode, not scaffolding, not "just a quick example."
46	2. One question per message. Compound questions produce shallow answers.
47	3. Open questions before closed questions. Explore before narrowing.
48	4. Challenge assumptions, not people. "Is X a hard requirement, or an assumption we should test?"
49	5. The user defines scope, not the agent. Surface possibilities through questions, let the user decide.
50	6. Non-goals are as important as goals. A spec without explicit non-goals has undefined boundaries.
51	7. Acceptance criteria must be testable. "It should be fast" is not testable. "Under 200ms at p95" is.
52	8. Scale depth to complexity. Simple features get short specs. System redesigns get thorough ones.
53	9. Resolve contradictions before locking scope.
54	10. The spec is a living document until approved.
55
56	---
57
58	## Question Technique
59
60	\| Principle \| Meaning \|
61	\|---\|---\|
62	\| One at a time \| One question, one message \|
63	\| Open before closed \| "What" and "why" first; "which" and "would you prefer" later \|
64	\| Challenge assumptions \| When something is stated as obvious, ask what would happen if it were not true \|
65	\| Surface constraints early \| Constraints eliminate solution space - the sooner known, the less rework \|
66	\| Offer options when narrowing \| Present 2-3 concrete choices instead of open-ended questions during convergence \|
67	\| Name the silence \| If an important topic has not come up, ask about it explicitly \|
68
69	See [question-playbook](references/question-playbook.md) for the full catalog.
70
71	---
72
73	## Anti-Patterns
74
75	\| Anti-Pattern \| Fix \|
76	\|---\|---\|
77	\| Solution jumping \| Stay in divergence until goals and constraints are clear \|
78	\| Compound questions \| One question per message \|
79	\| Leading questions \| Ask neutral: "What scale needs exist?" not "Should we use microservices?" \|
80	\| Premature implementation \| Hard-gate: no code until spec is approved \|
81	\| Fake consensus \| Probe: "Can you walk me through how you'd use this?" \|
82	\| Scope creep during convergence \| Park in "future considerations", re-lock scope \|
83
84	See [anti-patterns](references/anti-patterns.md) for the full guide.
85
86	---
87
88	## Reference Files
89
90	\| Reference \| Contents \|
91	\|---\|---\|
92	\| [question-playbook](references/question-playbook.md) \| Full catalog of

People who liked this also viewed

6 picks

Type

brainstorming

18installs1forks

View on GitHub

How to install brainstorming?

krzysztofsurdy/code-virtuoso/brainstorming

$npx -y skills add krzysztofsurdy/code-virtuoso --skill brainstorming

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Brainstorming
2
3	Structured pre-implementation design exploration. Transforms a vague idea into a written spec through focused, one-at-a-time questioning before any code is written, any plan is created, or any architecture is decided. The spec is the deliverable - everything else follows from it.
4
5	No code until the spec is written and approved.
6
7	## When to Use
8
9	- The user says "I want to build X" but has no written requirements
10	- A feature request exists as a sentence or two with no detail
11	- The user asks "how should I build X" before defining what X actually is
12	- Someone says "let's brainstorm" or "help me figure this out"
13	- A problem statement exists but the solution space is unexplored
14
15	## Quick Start
16
17	```
18	/brainstorming user authentication for a SaaS app
19	/brainstorming migrate our monolith to services
20	/brainstorming # asks what to explore
21	```
22
23	If `$ARGUMENTS` is provided, use it as the initial topic and skip straight to Phase 1. If no argument, ask: "What idea, feature, or problem would you like to explore?"
24
25	---
26
27	## Workflow
28
29	This skill uses guided phases - each phase is a separate file loaded one at a time. Every phase ends with a gate where you must wait for user confirmation before proceeding. Do not skip phases or merge them.
30
31	\| Phase \| File \| What it covers \|
32	\|---\|---\|---\|
33	\| 1 \| [Intake](phases/01-intake.md) \| Read context, classify maturity, summarize understanding \|
34	\| 2 \| [Divergence](phases/02-divergence.md) \| Expand problem space with one-at-a-time questions across 7 categories \|
35	\| 3 \| [Convergence](phases/03-convergence.md) \| Narrow to concrete scope, lock must-haves and non-goals \|
36	\| 4 \| [Spec Writing](phases/04-spec-writing.md) \| Write full spec from gathered material, run quality checklist \|
37	\| 5 \| [Approval](phases/05-approval.md) \| Get explicit user approval, hard-gate implementation \|
38
39	Start by loading Phase 1. After the user confirms each phase, load the next. Never load multiple phases at once. Never skip a phase.
40
41	---
42
43	## Critical Rules
44
45	1. No code until the spec is approved. Not pseudocode, not scaffolding, not "just a quick example."
46	2. One question per message. Compound questions produce shallow answers.
47	3. Open questions before closed questions. Explore before narrowing.
48	4. Challenge assumptions, not people. "Is X a hard requirement, or an assumption we should test?"
49	5. The user defines scope, not the agent. Surface possibilities through questions, let the user decide.
50	6. Non-goals are as important as goals. A spec without explicit non-goals has undefined boundaries.
51	7. Acceptance criteria must be testable. "It should be fast" is not testable. "Under 200ms at p95" is.
52	8. Scale depth to complexity. Simple features get short specs. System redesigns get thorough ones.
53	9. Resolve contradictions before locking scope.
54	10. The spec is a living document until approved.
55
56	---
57
58	## Question Technique
59
60	\| Principle \| Meaning \|
61	\|---\|---\|
62	\| One at a time \| One question, one message \|
63	\| Open before closed \| "What" and "why" first; "which" and "would you prefer" later \|
64	\| Challenge assumptions \| When something is stated as obvious, ask what would happen if it were not true \|
65	\| Surface constraints early \| Constraints eliminate solution space - the sooner known, the less rework \|
66	\| Offer options when narrowing \| Present 2-3 concrete choices instead of open-ended questions during convergence \|
67	\| Name the silence \| If an important topic has not come up, ask about it explicitly \|
68
69	See [question-playbook](references/question-playbook.md) for the full catalog.
70
71	---
72
73	## Anti-Patterns
74
75	\| Anti-Pattern \| Fix \|
76	\|---\|---\|
77	\| Solution jumping \| Stay in divergence until goals and constraints are clear \|
78	\| Compound questions \| One question per message \|
79	\| Leading questions \| Ask neutral: "What scale needs exist?" not "Should we use microservices?" \|
80	\| Premature implementation \| Hard-gate: no code until spec is approved \|
81	\| Fake consensus \| Probe: "Can you walk me through how you'd use this?" \|
82	\| Scope creep during convergence \| Park in "future considerations", re-lock scope \|
83
84	See [anti-patterns](references/anti-patterns.md) for the full guide.
85
86	---
87
88	## Reference Files
89
90	\| Reference \| Contents \|
91	\|---\|---\|
92	\| [question-playbook](references/question-playbook.md) \| Full catalog of

People who liked this also viewed

6 picks

Type