brainstorming

Name: brainstorming
Author: fusengine

21stars3forks

How to install brainstorming?

fusengine/agents/brainstorming

$npx -y skills add fusengine/agents --skill brainstorming

Installs into the current project.

Summary

Use when user requests creative work - creating features, building components, adding functionality, or modifying behavior. Activates BEFORE APEX Analyze phase to refine requirements through structured questioning.

Files · 1

View on GitHub

SKILL.md

1	# Brainstorming Skill
2
3	Design-first approach: no code before design approval.
4
5	---
6
7	## Agent Workflow (MANDATORY)
8
9	Before ANY brainstorming session, use `TeamCreate` to spawn agents:
10
11	1. fuse-ai-pilot:explore-codebase - Understand project context, patterns, constraints
12	2. fuse-ai-pilot:research-expert - Fetch best practices and documentation
13
14	After design approval, transition to APEX Analyze phase, passing along the explore-codebase and research-expert findings in the handoff (not just the design doc). APEX Analyze re-runs those same agents by default — carrying forward what was already gathered here avoids re-doing the same research twice.
15
16	---
17
18	## Overview
19
20	\| Scenario \| Action \|
21	\|----------\|--------\|
22	\| New feature \| Full brainstorming (6 steps) \|
23	\| Major change \| Full brainstorming (6 steps) \|
24	\| Component creation \| Full brainstorming (6 steps) \|
25	\| Trivial fix (1-3 lines) \| Skip brainstorming, go to APEX \|
26	\| Simple rename/typo \| Skip brainstorming, go to APEX \|
27
28	---
29
30	## 6-Step Process
31
32	### Step 1: Explore Project Context
33
34	Gather context before asking questions:
35
36	- `git log --oneline -20` - Recent changes and direction
37	- Existing code patterns and conventions
38	- Related documentation and prior decisions
39	- Tech stack and dependency constraints
40
41	### Step 2: Ask Clarifying Questions (ONE AT A TIME)
42
43	Ask focused questions sequentially. Wait for each answer before the next.
44
45	Categories: purpose, constraints, success criteria, users, integrations.
46
47	> See [workflow.md](references/workflow.md) for question categories
48
49	### Step 3: Diverge, Then Converge to 2-3 Approaches
50
51	Generate ≥6-8 distinct approaches via a named technique (SCAMPER / reverse-brainstorming / analogies), judgment suspended — not 3 sizes of the same idea. Only then converge to 2-3 with trade-offs in table format:
52
53	\| Approach \| Pros \| Cons \| Recommendation \|
54	\|----------\|------\|------\|----------------\|
55	\| Option A \| ... \| ... \| ... \|
56	\| Option B \| ... \| ... \| ... \|
57	\| Option C \| ... \| ... \| ... \|
58
59	Always include a clear recommendation with rationale.
60
61	### Step 4: Present Design for Approval
62
63	Break design into digestible sections:
64
65	1. Architecture overview
66	2. Key components and responsibilities
67	3. Data flow and state management
68	4. Edge cases and error handling
69
70	Wait for explicit user approval before proceeding.
71
72	### Step 5: Save Design Document
73
74	Save approved design to: `docs/plans/YYYY-MM-DD-<topic>-design.md`
75
76	### Step 6: Transition to APEX
77
78	Hand off to APEX Analyze phase with the approved design as input.
79
80	---
81
82	## Reference Guide
83
84	\| Topic \| Reference \| When to Consult \|
85	\|-------\|-----------\|-----------------\|
86	\| Workflow \| [workflow.md](references/workflow.md) \| Question categories, proposal format, design template \|
87	\| Anti-Patterns \| [anti-patterns.md](references/anti-patterns.md) \| Catching rationalizations to skip brainstorming \|
88
89	---
90
91	## Quick Reference
92
93	```text
94	1. Explore → git log, codebase, docs (agents in parallel)
95	2. Question → ONE AT A TIME, wait for answers
96	3. Diverge → 6-8 options (named technique), converge to 2-3 with trade-offs table
97	4. Design → Present sections, get approval
98	5. Save → docs/plans/YYYY-MM-DD-<topic>-design.md
99	6. Handoff → APEX Analyze with approved design + prior research (no re-research)
100	```
101
102	---
103
104	## Critical Rules
105
106	1. NEVER write code before design approval - Design first, always
107	2. Ask questions ONE AT A TIME - Never dump a list of 10 questions
108	3. Always propose alternatives - Minimum 2 approaches with trade-offs
109	4. Save the design doc - Creates audit trail and shared reference
110	5. Get explicit approval - "Looks good" or similar before proceeding

People who liked this also viewed

6 picks

Type

brainstorming

21stars3forks

View on GitHub

How to install brainstorming?

fusengine/agents/brainstorming

$npx -y skills add fusengine/agents --skill brainstorming

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Brainstorming Skill
2
3	Design-first approach: no code before design approval.
4
5	---
6
7	## Agent Workflow (MANDATORY)
8
9	Before ANY brainstorming session, use `TeamCreate` to spawn agents:
10
11	1. fuse-ai-pilot:explore-codebase - Understand project context, patterns, constraints
12	2. fuse-ai-pilot:research-expert - Fetch best practices and documentation
13
14	After design approval, transition to APEX Analyze phase, passing along the explore-codebase and research-expert findings in the handoff (not just the design doc). APEX Analyze re-runs those same agents by default — carrying forward what was already gathered here avoids re-doing the same research twice.
15
16	---
17
18	## Overview
19
20	\| Scenario \| Action \|
21	\|----------\|--------\|
22	\| New feature \| Full brainstorming (6 steps) \|
23	\| Major change \| Full brainstorming (6 steps) \|
24	\| Component creation \| Full brainstorming (6 steps) \|
25	\| Trivial fix (1-3 lines) \| Skip brainstorming, go to APEX \|
26	\| Simple rename/typo \| Skip brainstorming, go to APEX \|
27
28	---
29
30	## 6-Step Process
31
32	### Step 1: Explore Project Context
33
34	Gather context before asking questions:
35
36	- `git log --oneline -20` - Recent changes and direction
37	- Existing code patterns and conventions
38	- Related documentation and prior decisions
39	- Tech stack and dependency constraints
40
41	### Step 2: Ask Clarifying Questions (ONE AT A TIME)
42
43	Ask focused questions sequentially. Wait for each answer before the next.
44
45	Categories: purpose, constraints, success criteria, users, integrations.
46
47	> See [workflow.md](references/workflow.md) for question categories
48
49	### Step 3: Diverge, Then Converge to 2-3 Approaches
50
51	Generate ≥6-8 distinct approaches via a named technique (SCAMPER / reverse-brainstorming / analogies), judgment suspended — not 3 sizes of the same idea. Only then converge to 2-3 with trade-offs in table format:
52
53	\| Approach \| Pros \| Cons \| Recommendation \|
54	\|----------\|------\|------\|----------------\|
55	\| Option A \| ... \| ... \| ... \|
56	\| Option B \| ... \| ... \| ... \|
57	\| Option C \| ... \| ... \| ... \|
58
59	Always include a clear recommendation with rationale.
60
61	### Step 4: Present Design for Approval
62
63	Break design into digestible sections:
64
65	1. Architecture overview
66	2. Key components and responsibilities
67	3. Data flow and state management
68	4. Edge cases and error handling
69
70	Wait for explicit user approval before proceeding.
71
72	### Step 5: Save Design Document
73
74	Save approved design to: `docs/plans/YYYY-MM-DD-<topic>-design.md`
75
76	### Step 6: Transition to APEX
77
78	Hand off to APEX Analyze phase with the approved design as input.
79
80	---
81
82	## Reference Guide
83
84	\| Topic \| Reference \| When to Consult \|
85	\|-------\|-----------\|-----------------\|
86	\| Workflow \| [workflow.md](references/workflow.md) \| Question categories, proposal format, design template \|
87	\| Anti-Patterns \| [anti-patterns.md](references/anti-patterns.md) \| Catching rationalizations to skip brainstorming \|
88
89	---
90
91	## Quick Reference
92
93	```text
94	1. Explore → git log, codebase, docs (agents in parallel)
95	2. Question → ONE AT A TIME, wait for answers
96	3. Diverge → 6-8 options (named technique), converge to 2-3 with trade-offs table
97	4. Design → Present sections, get approval
98	5. Save → docs/plans/YYYY-MM-DD-<topic>-design.md
99	6. Handoff → APEX Analyze with approved design + prior research (no re-research)
100	```
101
102	---
103
104	## Critical Rules
105
106	1. NEVER write code before design approval - Design first, always
107	2. Ask questions ONE AT A TIME - Never dump a list of 10 questions
108	3. Always propose alternatives - Minimum 2 approaches with trade-offs
109	4. Save the design doc - Creates audit trail and shared reference
110	5. Get explicit approval - "Looks good" or similar before proceeding

People who liked this also viewed

6 picks

Type