brainstorming

Name: brainstorming
Author: sabahattink

27stars9forks

How to install brainstorming?

sabahattink/antigravity-fullstack-hq/brainstorming

$npx -y skills add sabahattink/antigravity-fullstack-hq --skill brainstorming

Installs into the current project.

Summary

Structured brainstorming techniques, idea generation, trade-off analysis. Use when exploring design options, choosing between architectural approaches, generating feature ideas, or making technology decisions.

Files · 1

View on GitHub

SKILL.md

1	# Brainstorming
2
3	## When to Brainstorm vs When to Decide
4
5	Brainstorm when:
6	- Multiple valid approaches exist
7	- You don't yet know the constraints
8	- The cost of choosing wrong is high
9	- You want to surface blind spots
10
11	Decide immediately when:
12	- One approach is clearly better
13	- Time is critical and any reasonable option works
14	- The decision is easily reversible
15
16	## Technique 1: Six Thinking Hats
17
18	Work through each lens sequentially before converging.
19
20	```
21	WHITE HAT — Facts & Data
22	"What do we know for certain?"
23	"What data do we have? What data do we need?"
24	Example: "We have 10k users. P95 response time is 2s. Database has 1M rows."
25
26	RED HAT — Gut Feelings & Emotions
27	"What feels wrong about this?"
28	"What are we uncomfortable with?"
29	Example: "This approach feels fragile. I'm not confident in the third-party service."
30
31	BLACK HAT — Critical Thinking & Risks
32	"What could go wrong?"
33	"What are the weaknesses?"
34	Example: "If the cache fails, we hit the DB directly and it falls over."
35
36	YELLOW HAT — Optimism & Benefits
37	"What's the best-case scenario?"
38	"What does success look like?"
39	Example: "If this works, we reduce load by 80% and can scale without upgrading the DB."
40
41	GREEN HAT — Creativity & Alternatives
42	"What else could we do?"
43	"Are there completely different approaches?"
44	Example: "What if we precomputed this nightly? What if we used read replicas?"
45
46	BLUE HAT — Process & Facilitation
47	"What's our decision process?"
48	"What do we need to decide today vs later?"
49	Example: "We need to pick an approach now for sprint planning. Cache vs CDN can be decided next sprint."
50	```
51
52	## Technique 2: Diverge-Converge
53
54	```
55	DIVERGE (10 minutes — no judgment)
56	Generate as many options as possible
57	Crazy options are welcome — they often contain the seed of the real solution
58	No evaluation, no "but", no "however"
59
60	CONVERGE (10 minutes — structured evaluation)
61	Group similar options
62	Apply constraints to eliminate non-starters
63	Score remaining options on key criteria
64	Select top 2-3 for detailed analysis
65	```
66
67	## Technique 3: How Might We (HMW)
68
69	Reframe problems as opportunities.
70
71	```
72	Problem: "Users don't complete onboarding"
73	HMW: "How might we make onboarding feel like progress, not work?"
74	HMW: "How might we surface value before asking for effort?"
75	HMW: "How might we let users skip steps they've done elsewhere?"
76
77	Problem: "The API is slow under load"
78	HMW: "How might we reduce the number of DB queries per request?"
79	HMW: "How might we serve cached responses for read-heavy endpoints?"
80	HMW: "How might we move expensive work out of the request path entirely?"
81	```
82
83	## Technique 4: Pre-Mortem
84
85	Imagine it's 6 months from now and the project failed spectacularly.
86	Work backwards to find what caused it.
87
88	```
89	"It's October. The launch went badly. What happened?"
90
91	Participants each write 3-5 reasons it failed:
92	- "We underestimated the data migration complexity"
93	- "The third-party auth provider had an outage on launch day"
94	- "The mobile app wasn't tested on Android 12"
95	- "We shipped without rate limiting and got scraped"
96
97	Now: address the most plausible failure modes before you start.
98	```
99
100	## Trade-off Analysis Matrix
101
102	```typescript
103	// Template for comparing options on explicit criteria
104
105	interface Option {
106	name: string
107	scores: Record<string, number> // 1-5
108	}
109
110	interface Criterion {
111	name: string
112	weight: number // 0-1, sums to 1.0
113	}
114
115	function scoreOptions(options: Option[], criteria: Criterion[]): ScoredOption[] {
116	return options.map(option => {
117	const total = criteria.reduce((sum, criterion) => {
118	const score = option.scores[criterion.name] ?? 0
119	return sum + score * criterion.weight
120	}, 0)
121	return { ...option, total }
122	}).sort((a, b) => b.total - a.total)
123	}
124
125	// Example: Choosing a caching strategy
126	const criteria: Criterion[] = [
127	{ name: 'Simplicity', weight: 0.25 },
128	{ name: 'Performance', weight: 0.35 },
129	{ name: 'Reliability', weight: 0.25 },
130	{ name: 'Cost', weight: 0.15 },
131	]
132
133	const options: Option[] = [
134	{
135	name: 'Redis (external)',
136	scores: { Simplicity: 3, Performance: 5, Reliability: 4, Cost: 3 },
137	},
138	{
139	name: 'In-memory (LRU)',
140	scores: { Simplicity: 5, Performance: 5, Reliability: 2, Cost: 5 },
141	},
142	{
143	name: 'Database query cache',
144	scores: { Simplicity: 4, Performance: 3, Reliability: 5, Cost: 5 },
145	},
146	]
147	```
148
149	## Architecture Decision Template
150
151	```markdown
152	## Problem
153	[One paragraph describing the problem clearly]
154
155	## Constraints
156	- Must integrate with existing TypeORM setup
157	- P95 response must be < 500ms
158	- Team has 3 days for implementation
159
160	## Options Considered
161
162	### Option 1: [Name]
163	Description: ...
164	Pros: ...
165	Cons: ...
166	Effort: S / M / L
167
168	### Option 2

People who liked this also viewed

6 picks

Type

brainstorming

27stars9forks

View on GitHub

How to install brainstorming?

sabahattink/antigravity-fullstack-hq/brainstorming

$npx -y skills add sabahattink/antigravity-fullstack-hq --skill brainstorming

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Brainstorming
2
3	## When to Brainstorm vs When to Decide
4
5	Brainstorm when:
6	- Multiple valid approaches exist
7	- You don't yet know the constraints
8	- The cost of choosing wrong is high
9	- You want to surface blind spots
10
11	Decide immediately when:
12	- One approach is clearly better
13	- Time is critical and any reasonable option works
14	- The decision is easily reversible
15
16	## Technique 1: Six Thinking Hats
17
18	Work through each lens sequentially before converging.
19
20	```
21	WHITE HAT — Facts & Data
22	"What do we know for certain?"
23	"What data do we have? What data do we need?"
24	Example: "We have 10k users. P95 response time is 2s. Database has 1M rows."
25
26	RED HAT — Gut Feelings & Emotions
27	"What feels wrong about this?"
28	"What are we uncomfortable with?"
29	Example: "This approach feels fragile. I'm not confident in the third-party service."
30
31	BLACK HAT — Critical Thinking & Risks
32	"What could go wrong?"
33	"What are the weaknesses?"
34	Example: "If the cache fails, we hit the DB directly and it falls over."
35
36	YELLOW HAT — Optimism & Benefits
37	"What's the best-case scenario?"
38	"What does success look like?"
39	Example: "If this works, we reduce load by 80% and can scale without upgrading the DB."
40
41	GREEN HAT — Creativity & Alternatives
42	"What else could we do?"
43	"Are there completely different approaches?"
44	Example: "What if we precomputed this nightly? What if we used read replicas?"
45
46	BLUE HAT — Process & Facilitation
47	"What's our decision process?"
48	"What do we need to decide today vs later?"
49	Example: "We need to pick an approach now for sprint planning. Cache vs CDN can be decided next sprint."
50	```
51
52	## Technique 2: Diverge-Converge
53
54	```
55	DIVERGE (10 minutes — no judgment)
56	Generate as many options as possible
57	Crazy options are welcome — they often contain the seed of the real solution
58	No evaluation, no "but", no "however"
59
60	CONVERGE (10 minutes — structured evaluation)
61	Group similar options
62	Apply constraints to eliminate non-starters
63	Score remaining options on key criteria
64	Select top 2-3 for detailed analysis
65	```
66
67	## Technique 3: How Might We (HMW)
68
69	Reframe problems as opportunities.
70
71	```
72	Problem: "Users don't complete onboarding"
73	HMW: "How might we make onboarding feel like progress, not work?"
74	HMW: "How might we surface value before asking for effort?"
75	HMW: "How might we let users skip steps they've done elsewhere?"
76
77	Problem: "The API is slow under load"
78	HMW: "How might we reduce the number of DB queries per request?"
79	HMW: "How might we serve cached responses for read-heavy endpoints?"
80	HMW: "How might we move expensive work out of the request path entirely?"
81	```
82
83	## Technique 4: Pre-Mortem
84
85	Imagine it's 6 months from now and the project failed spectacularly.
86	Work backwards to find what caused it.
87
88	```
89	"It's October. The launch went badly. What happened?"
90
91	Participants each write 3-5 reasons it failed:
92	- "We underestimated the data migration complexity"
93	- "The third-party auth provider had an outage on launch day"
94	- "The mobile app wasn't tested on Android 12"
95	- "We shipped without rate limiting and got scraped"
96
97	Now: address the most plausible failure modes before you start.
98	```
99
100	## Trade-off Analysis Matrix
101
102	```typescript
103	// Template for comparing options on explicit criteria
104
105	interface Option {
106	name: string
107	scores: Record<string, number> // 1-5
108	}
109
110	interface Criterion {
111	name: string
112	weight: number // 0-1, sums to 1.0
113	}
114
115	function scoreOptions(options: Option[], criteria: Criterion[]): ScoredOption[] {
116	return options.map(option => {
117	const total = criteria.reduce((sum, criterion) => {
118	const score = option.scores[criterion.name] ?? 0
119	return sum + score * criterion.weight
120	}, 0)
121	return { ...option, total }
122	}).sort((a, b) => b.total - a.total)
123	}
124
125	// Example: Choosing a caching strategy
126	const criteria: Criterion[] = [
127	{ name: 'Simplicity', weight: 0.25 },
128	{ name: 'Performance', weight: 0.35 },
129	{ name: 'Reliability', weight: 0.25 },
130	{ name: 'Cost', weight: 0.15 },
131	]
132
133	const options: Option[] = [
134	{
135	name: 'Redis (external)',
136	scores: { Simplicity: 3, Performance: 5, Reliability: 4, Cost: 3 },
137	},
138	{
139	name: 'In-memory (LRU)',
140	scores: { Simplicity: 5, Performance: 5, Reliability: 2, Cost: 5 },
141	},
142	{
143	name: 'Database query cache',
144	scores: { Simplicity: 4, Performance: 3, Reliability: 5, Cost: 5 },
145	},
146	]
147	```
148
149	## Architecture Decision Template
150
151	```markdown
152	## Problem
153	[One paragraph describing the problem clearly]
154
155	## Constraints
156	- Must integrate with existing TypeORM setup
157	- P95 response must be < 500ms
158	- Team has 3 days for implementation
159
160	## Options Considered
161
162	### Option 1: [Name]
163	Description: ...
164	Pros: ...
165	Cons: ...
166	Effort: S / M / L
167
168	### Option 2

People who liked this also viewed

6 picks

Type