brainstorming

Name: brainstorming
Author: heymegabyte

18stars4forks

How to install brainstorming?

heymegabyte/claude-skills/brainstorming

$npx -y skills add heymegabyte/claude-skills --skill brainstorming

Installs into the current project.

Summary

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Files · 1

View on GitHub

SKILL.md

1	# Brainstorming Ideas Into Designs
2
3	Turn ideas into designs through collaborative dialogue, BEFORE any code. Pairs with Brian's `14-independent-idea-engine` and the SUPREME "brainstorm-first" rule.
4
5	<HARD-GATE>
6	No implementation skill, code, scaffold, or implementation action until a design is presented AND the user approves it. EVERY project, regardless of perceived simplicity.
7	</HARD-GATE>
8
9	## "Too simple to need a design" is the trap
10
11	"Simple" projects (todo list, one-function util, config change) hide the most unexamined assumptions. Design can be a few sentences — but present it and get approval.
12
13	## Checklist (one task each, in order)
14
15	1. Explore project context — files, docs, recent commits. Follow existing patterns.
16	2. Offer the visual companion just-in-time — NOT upfront. Offer (own message) the first time a question is genuinely clearer shown than told; never if no visual question arises. See `visual-companion.md`.
17	3. Ask clarifying questions — one per message, multiple-choice preferred. Purpose / constraints / success criteria.
18	4. Propose 2-3 approaches — trade-offs, lead with your recommendation + why.
19	5. Present design — sections scaled to complexity (sentences → 200-300 words). Approval after each. Cover architecture, components, data flow, error handling, testing.
20	6. Write design doc — `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` (user pref overrides path), commit.
21	7. Spec self-review — inline scan: placeholders/TBD, contradictions, ambiguity, scope. Fix and move on; no re-review.
22	8. User reviews written spec — ask, wait. Changes → fix + re-review. Proceed only on approval.
23	9. Transition — invoke `writing-plans`. This is the ONLY skill you invoke next — never frontend-design, mcp-builder, or any other implementation skill.
24
25	## Scope before refining
26
27	- If the request spans multiple independent subsystems (chat + storage + billing + analytics), flag it BEFORE refining details.
28	- Too large for one spec → decompose into sub-projects (pieces, relations, build order); brainstorm the first through the normal flow. Each sub-project gets its own spec → plan → implement cycle.
29
30	## Design for isolation
31
32	- Split into units with one clear purpose, well-defined interfaces, independently testable. For each: what it does, how to use it, what it depends on.
33	- Can someone understand a unit without reading internals? Can you change internals without breaking consumers? If not, boundaries need work. A file growing large signals it does too much.
34
35	## Working in existing code
36
37	- Explore structure first; follow existing patterns.
38	- Fold in targeted improvements where existing problems affect the work (oversized file, tangled responsibilities) — like a good dev improving code they touch. No unrelated refactoring.
39
40	## Principles
41
42	- One question at a time; multiple-choice preferred.
43	- YAGNI ruthlessly. Always explore 2-3 approaches. Validate incrementally. Go back and clarify when something doesn't fit.
44
45	## Visual Companion (summary)
46
47	A browser tool, not a mode — available for visual questions, doesn't route every question through the browser.
48
49	- Offer just-in-time, as its own message — no other content. Wait for response. Accept → start server with `--open`. Decline → text-only, don't re-offer.
50	- Decide per question: would the user understand this better seen than read? Browser for mockups / wireframes / layout comparisons / diagrams; terminal for requirements / concepts / tradeoffs / scope. A UI topic is not automatically a visual question.
51	- On accept, read `visual-companion.md` before proceeding.
52
53	<!-- budget: ~56 -->

People who liked this also viewed

6 picks

Type

brainstorming

18stars4forks

View on GitHub

How to install brainstorming?

heymegabyte/claude-skills/brainstorming

$npx -y skills add heymegabyte/claude-skills --skill brainstorming

Installs into the current project.

Summary

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Files · 1

View on GitHub

SKILL.md

1	# Brainstorming Ideas Into Designs
2
3	Turn ideas into designs through collaborative dialogue, BEFORE any code. Pairs with Brian's `14-independent-idea-engine` and the SUPREME "brainstorm-first" rule.
4
5	<HARD-GATE>
6	No implementation skill, code, scaffold, or implementation action until a design is presented AND the user approves it. EVERY project, regardless of perceived simplicity.
7	</HARD-GATE>
8
9	## "Too simple to need a design" is the trap
10
11	"Simple" projects (todo list, one-function util, config change) hide the most unexamined assumptions. Design can be a few sentences — but present it and get approval.
12
13	## Checklist (one task each, in order)
14
15	1. Explore project context — files, docs, recent commits. Follow existing patterns.
16	2. Offer the visual companion just-in-time — NOT upfront. Offer (own message) the first time a question is genuinely clearer shown than told; never if no visual question arises. See `visual-companion.md`.
17	3. Ask clarifying questions — one per message, multiple-choice preferred. Purpose / constraints / success criteria.
18	4. Propose 2-3 approaches — trade-offs, lead with your recommendation + why.
19	5. Present design — sections scaled to complexity (sentences → 200-300 words). Approval after each. Cover architecture, components, data flow, error handling, testing.
20	6. Write design doc — `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` (user pref overrides path), commit.
21	7. Spec self-review — inline scan: placeholders/TBD, contradictions, ambiguity, scope. Fix and move on; no re-review.
22	8. User reviews written spec — ask, wait. Changes → fix + re-review. Proceed only on approval.
23	9. Transition — invoke `writing-plans`. This is the ONLY skill you invoke next — never frontend-design, mcp-builder, or any other implementation skill.
24
25	## Scope before refining
26
27	- If the request spans multiple independent subsystems (chat + storage + billing + analytics), flag it BEFORE refining details.
28	- Too large for one spec → decompose into sub-projects (pieces, relations, build order); brainstorm the first through the normal flow. Each sub-project gets its own spec → plan → implement cycle.
29
30	## Design for isolation
31
32	- Split into units with one clear purpose, well-defined interfaces, independently testable. For each: what it does, how to use it, what it depends on.
33	- Can someone understand a unit without reading internals? Can you change internals without breaking consumers? If not, boundaries need work. A file growing large signals it does too much.
34
35	## Working in existing code
36
37	- Explore structure first; follow existing patterns.
38	- Fold in targeted improvements where existing problems affect the work (oversized file, tangled responsibilities) — like a good dev improving code they touch. No unrelated refactoring.
39
40	## Principles
41
42	- One question at a time; multiple-choice preferred.
43	- YAGNI ruthlessly. Always explore 2-3 approaches. Validate incrementally. Go back and clarify when something doesn't fit.
44
45	## Visual Companion (summary)
46
47	A browser tool, not a mode — available for visual questions, doesn't route every question through the browser.
48
49	- Offer just-in-time, as its own message — no other content. Wait for response. Accept → start server with `--open`. Decline → text-only, don't re-offer.
50	- Decide per question: would the user understand this better seen than read? Browser for mockups / wireframes / layout comparisons / diagrams; terminal for requirements / concepts / tradeoffs / scope. A UI topic is not automatically a visual question.
51	- On accept, read `visual-companion.md` before proceeding.
52
53	<!-- budget: ~56 -->

People who liked this also viewed

6 picks

Type