@musashishao/agent-kit 1.0.0 → 1.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Potentially problematic release.
This version of @musashishao/agent-kit might be problematic. Click here for more details.
- package/.agent/ARCHITECTURE.md +4 -2
- package/.agent/skills/mcp-builder/SKILL.md +583 -97
- package/.agent/skills/mcp-builder/python-template.md +522 -0
- package/.agent/skills/mcp-builder/tool-patterns.md +642 -0
- package/.agent/skills/mcp-builder/typescript-template.md +361 -0
- package/.agent/skills/problem-solving/SKILL.md +556 -0
- package/.agent/skills/problem-solving/collision-zone-thinking.md +285 -0
- package/.agent/skills/problem-solving/inversion-exercise.md +205 -0
- package/.agent/skills/problem-solving/meta-pattern-recognition.md +313 -0
- package/.agent/skills/problem-solving/scale-game.md +300 -0
- package/.agent/skills/problem-solving/simplification-cascades.md +321 -0
- package/.agent/skills/problem-solving/when-stuck.md +146 -0
- package/package.json +2 -2
|
@@ -0,0 +1,285 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: collision-zone-thinking
|
|
3
|
+
parent: problem-solving
|
|
4
|
+
description: Force unrelated concepts together to discover emergent properties. "What if we treated X like Y?"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Collision Zone Thinking
|
|
8
|
+
|
|
9
|
+
> Creativity happens at the intersection of unrelated ideas.
|
|
10
|
+
|
|
11
|
+
## When to Use
|
|
12
|
+
|
|
13
|
+
- Incremental improvements aren't enough
|
|
14
|
+
- You need a creative breakthrough
|
|
15
|
+
- "We've tried everything" feeling
|
|
16
|
+
- Looking for innovation, not optimization
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## The 4-Step Process
|
|
21
|
+
|
|
22
|
+
### Step 1: Define Your Problem Space
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
What are you trying to solve?
|
|
26
|
+
|
|
27
|
+
Problem: Onboarding new developers takes 3 weeks
|
|
28
|
+
Current domain: HR, Training, Documentation
|
|
29
|
+
Current solutions: Docs, pair programming, bootcamp
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
### Step 2: Generate Random Domains
|
|
33
|
+
|
|
34
|
+
Pick domains COMPLETELY unrelated to your problem:
|
|
35
|
+
|
|
36
|
+
**Domain Generator (pick 3-5):**
|
|
37
|
+
```
|
|
38
|
+
Entertainment: Video games, Theme parks, Movies, Music
|
|
39
|
+
Food: Restaurants, Cooking shows, Farming
|
|
40
|
+
Travel: Airports, Hotels, Tourism, Maps
|
|
41
|
+
Health: Hospitals, Gyms, Mental health
|
|
42
|
+
Nature: Ecosystems, Weather, Evolution
|
|
43
|
+
Sports: Team sports, Olympics, Training
|
|
44
|
+
Military: Strategy, Logistics, Training
|
|
45
|
+
Retail: Shopping malls, E-commerce, Fashion
|
|
46
|
+
Education: Schools, Universities, Tutoring
|
|
47
|
+
Construction: Architecture, Building, Infrastructure
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
**For this example:**
|
|
51
|
+
- Video games
|
|
52
|
+
- Restaurant kitchens
|
|
53
|
+
- Airport security
|
|
54
|
+
- Theme parks
|
|
55
|
+
|
|
56
|
+
### Step 3: Force Collisions
|
|
57
|
+
|
|
58
|
+
Take each random domain and FORCE a collision:
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
|
|
62
|
+
#### 🎮 "What if developer onboarding was like a VIDEO GAME?"
|
|
63
|
+
|
|
64
|
+
| Game Element | Onboarding Translation |
|
|
65
|
+
|--------------|----------------------|
|
|
66
|
+
| Tutorial level | First-day guided walkthrough |
|
|
67
|
+
| Quests | Small, clear tasks with completion |
|
|
68
|
+
| XP and leveling | Progress tracking, badges |
|
|
69
|
+
| Achievement unlocks | Access to new repos/systems |
|
|
70
|
+
| NPCs and guides | Bots that answer questions |
|
|
71
|
+
| Multiplayer | Collaborative challenges |
|
|
72
|
+
| Save points | Checkpoints to resume |
|
|
73
|
+
| Difficulty settings | Customize based on experience |
|
|
74
|
+
| Leaderboard | Friendly competition |
|
|
75
|
+
| Boss battles | Major milestone reviews |
|
|
76
|
+
|
|
77
|
+
**Emergent idea:** "Developer Quest System"
|
|
78
|
+
- Day 1: Complete 3 starting quests (setup, first commit, code review)
|
|
79
|
+
- Week 1: Earn "Backend Badge" by completing module
|
|
80
|
+
- Gamified progress visible to team
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
84
|
+
#### 🍳 "What if developer onboarding was like a RESTAURANT KITCHEN?"
|
|
85
|
+
|
|
86
|
+
| Kitchen Element | Onboarding Translation |
|
|
87
|
+
|-----------------|----------------------|
|
|
88
|
+
| Station training | Master one area first |
|
|
89
|
+
| Mise en place | Prep environment before "service" |
|
|
90
|
+
| Line cooking | Work alongside experienced "chef" |
|
|
91
|
+
| Restaurant rush | Simulate real workload |
|
|
92
|
+
| Tasting | Code review like dish approval |
|
|
93
|
+
| Recipe cards | Runbooks for common tasks |
|
|
94
|
+
| Sous chef mentorship | Senior dev assigned |
|
|
95
|
+
| Kitchen hierarchy | Clear escalation path |
|
|
96
|
+
|
|
97
|
+
**Emergent idea:** "Station Mastery"
|
|
98
|
+
- Each new hire masters ONE system first
|
|
99
|
+
- Only move to next "station" when proficient
|
|
100
|
+
- "Sous chef" (senior dev) signs off on each station
|
|
101
|
+
|
|
102
|
+
---
|
|
103
|
+
|
|
104
|
+
#### 🛫 "What if developer onboarding was like AIRPORT SECURITY?"
|
|
105
|
+
|
|
106
|
+
| Airport Element | Onboarding Translation |
|
|
107
|
+
|-----------------|----------------------|
|
|
108
|
+
| Clear checkpoints | Must pass each step |
|
|
109
|
+
| ID verification | Verify credentials/access |
|
|
110
|
+
| Fast lane (PreCheck) | Skip steps if experienced |
|
|
111
|
+
| Screening | Assess skills upfront |
|
|
112
|
+
| Boarding zones | Graduate access by group |
|
|
113
|
+
| Delays | Known blockers flagged early |
|
|
114
|
+
| Information displays | Status visible to all |
|
|
115
|
+
|
|
116
|
+
**Emergent idea:** "PreCheck for Experienced Hires"
|
|
117
|
+
- Assessment at start to skip known skills
|
|
118
|
+
- "Fast lane" for senior engineers
|
|
119
|
+
- Clear checkpoint status visible
|
|
120
|
+
|
|
121
|
+
---
|
|
122
|
+
|
|
123
|
+
#### 🎢 "What if developer onboarding was like a THEME PARK?"
|
|
124
|
+
|
|
125
|
+
| Theme Park Element | Onboarding Translation |
|
|
126
|
+
|-------------------|----------------------|
|
|
127
|
+
| Park map | Visual overview of journey |
|
|
128
|
+
| Ride height requirements | Prerequisites clearly marked |
|
|
129
|
+
| Fast pass | Priority access for critical paths |
|
|
130
|
+
| Character meet & greet | Meet key team members |
|
|
131
|
+
| Park sections | Themed learning areas |
|
|
132
|
+
| Ride photos | Celebrate completions |
|
|
133
|
+
| Closing time | Time-boxed onboarding |
|
|
134
|
+
|
|
135
|
+
**Emergent idea:** "Onboarding Theme Park Map"
|
|
136
|
+
- Visual journey map on day 1
|
|
137
|
+
- "Lands" = different tech areas
|
|
138
|
+
- "Rides" = learning experiences
|
|
139
|
+
- "Fast pass" = skip if expert
|
|
140
|
+
|
|
141
|
+
---
|
|
142
|
+
|
|
143
|
+
### Step 4: Extract and Combine Best Ideas
|
|
144
|
+
|
|
145
|
+
| Winning Idea | From Domain | Why It Works |
|
|
146
|
+
|--------------|-------------|--------------|
|
|
147
|
+
| Quest system | Video games | Clear goals, dopamine hits |
|
|
148
|
+
| Station mastery | Kitchen | Deep before broad |
|
|
149
|
+
| PreCheck skip | Airport | Respects prior experience |
|
|
150
|
+
| Visual map | Theme park | Big picture orientation |
|
|
151
|
+
|
|
152
|
+
**Final Solution: "Developer Quest Park"**
|
|
153
|
+
1. Visual map of entire onboarding journey (theme park)
|
|
154
|
+
2. Quest-based progression with badges (games)
|
|
155
|
+
3. Station mastery: depth before breadth (kitchen)
|
|
156
|
+
4. PreCheck assessment to skip known areas (airport)
|
|
157
|
+
|
|
158
|
+
**Result:** 3 weeks → 1 week for most developers
|
|
159
|
+
|
|
160
|
+
---
|
|
161
|
+
|
|
162
|
+
## Collision Prompt Templates
|
|
163
|
+
|
|
164
|
+
```
|
|
165
|
+
"What if [YOUR PROBLEM] worked like [RANDOM DOMAIN]?"
|
|
166
|
+
|
|
167
|
+
Examples:
|
|
168
|
+
- What if code review worked like restaurant quality control?
|
|
169
|
+
- What if deployment worked like a rocket launch?
|
|
170
|
+
- What if debugging worked like medical diagnosis?
|
|
171
|
+
- What if refactoring worked like home renovation?
|
|
172
|
+
- What if meetings worked like improv comedy?
|
|
173
|
+
- What if documentation worked like a museum tour?
|
|
174
|
+
- What if testing worked like flight simulation?
|
|
175
|
+
- What if hiring worked like sports drafting?
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
---
|
|
179
|
+
|
|
180
|
+
## Domain Inspiration Cards
|
|
181
|
+
|
|
182
|
+
Copy and randomly pick one:
|
|
183
|
+
|
|
184
|
+
```
|
|
185
|
+
🎰 RANDOM DOMAIN PICKER
|
|
186
|
+
|
|
187
|
+
Roll a number 1-20:
|
|
188
|
+
1. Cooking competition
|
|
189
|
+
2. Emergency room
|
|
190
|
+
3. Orchestra performance
|
|
191
|
+
4. Space mission
|
|
192
|
+
5. Detective investigation
|
|
193
|
+
6. Gardening
|
|
194
|
+
7. Wedding planning
|
|
195
|
+
8. Movie production
|
|
196
|
+
9. Military operation
|
|
197
|
+
10. Stand-up comedy
|
|
198
|
+
11. Fashion runway
|
|
199
|
+
12. Archaeology dig
|
|
200
|
+
13. Video game speedrun
|
|
201
|
+
14. Restaurant reservation
|
|
202
|
+
15. Air traffic control
|
|
203
|
+
16. Book publishing
|
|
204
|
+
17. Music festival
|
|
205
|
+
18. Court trial
|
|
206
|
+
19. Nature documentary
|
|
207
|
+
20. Magic show
|
|
208
|
+
```
|
|
209
|
+
|
|
210
|
+
---
|
|
211
|
+
|
|
212
|
+
## Common Collision Discoveries
|
|
213
|
+
|
|
214
|
+
| Your Problem | Good Collision Domains |
|
|
215
|
+
|--------------|----------------------|
|
|
216
|
+
| User engagement | Games, casinos, social media |
|
|
217
|
+
| Speed/performance | Racing, fast food, emergency services |
|
|
218
|
+
| Quality | Luxury brands, fine dining, craftsmanship |
|
|
219
|
+
| Collaboration | Jazz bands, sports teams, improv |
|
|
220
|
+
| Learning | Schools, games, driving lessons |
|
|
221
|
+
| Scale | Logistics, supply chain, crowds |
|
|
222
|
+
| Trust | Banking, medicine, marriage |
|
|
223
|
+
|
|
224
|
+
---
|
|
225
|
+
|
|
226
|
+
## Practice Exercise
|
|
227
|
+
|
|
228
|
+
### Your Problem:
|
|
229
|
+
> _______________________________________________
|
|
230
|
+
|
|
231
|
+
### Random Domains (pick 3):
|
|
232
|
+
1. _______________________________________________
|
|
233
|
+
2. _______________________________________________
|
|
234
|
+
3. _______________________________________________
|
|
235
|
+
|
|
236
|
+
### Collision 1: "What if my problem worked like [Domain 1]?"
|
|
237
|
+
| Domain Element | My Problem Translation |
|
|
238
|
+
|----------------|----------------------|
|
|
239
|
+
| | |
|
|
240
|
+
| | |
|
|
241
|
+
| | |
|
|
242
|
+
|
|
243
|
+
**Emergent idea:** _______________________________________________
|
|
244
|
+
|
|
245
|
+
### Collision 2: "What if my problem worked like [Domain 2]?"
|
|
246
|
+
| Domain Element | My Problem Translation |
|
|
247
|
+
|----------------|----------------------|
|
|
248
|
+
| | |
|
|
249
|
+
| | |
|
|
250
|
+
| | |
|
|
251
|
+
|
|
252
|
+
**Emergent idea:** _______________________________________________
|
|
253
|
+
|
|
254
|
+
### Best Combined Idea:
|
|
255
|
+
> _______________________________________________
|
|
256
|
+
|
|
257
|
+
---
|
|
258
|
+
|
|
259
|
+
## Quick Reference
|
|
260
|
+
|
|
261
|
+
```
|
|
262
|
+
COLLISION ZONE IN 60 SECONDS:
|
|
263
|
+
|
|
264
|
+
1. What's my problem?
|
|
265
|
+
→ "I'm trying to improve [X]"
|
|
266
|
+
|
|
267
|
+
2. What's a random domain?
|
|
268
|
+
→ *pick from list above*
|
|
269
|
+
|
|
270
|
+
3. Force the collision:
|
|
271
|
+
→ "What if [X] worked like [random domain]?"
|
|
272
|
+
|
|
273
|
+
4. List elements of that domain:
|
|
274
|
+
→ "In [domain], they have [A], [B], [C]..."
|
|
275
|
+
|
|
276
|
+
5. Translate each:
|
|
277
|
+
→ "In my problem, that would mean..."
|
|
278
|
+
|
|
279
|
+
6. Find the gem:
|
|
280
|
+
→ "The interesting idea here is..."
|
|
281
|
+
```
|
|
282
|
+
|
|
283
|
+
---
|
|
284
|
+
|
|
285
|
+
> **Remember:** The more unrelated the domain, the more creative the collision. If it feels weird, you're doing it right. The magic happens when you force yourself to translate concepts that "shouldn't" fit.
|
|
@@ -0,0 +1,205 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: inversion-exercise
|
|
3
|
+
parent: problem-solving
|
|
4
|
+
description: Flip core assumptions to reveal hidden constraints and alternative approaches. "What if the opposite were true?"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Inversion Exercise
|
|
8
|
+
|
|
9
|
+
> Challenge every assumption by exploring its opposite.
|
|
10
|
+
|
|
11
|
+
## When to Use
|
|
12
|
+
|
|
13
|
+
- You feel stuck because of "the way things are"
|
|
14
|
+
- Conventional approaches have failed
|
|
15
|
+
- You suspect hidden assumptions are blocking you
|
|
16
|
+
- Need a fresh perspective on an old problem
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## The 4-Step Process
|
|
21
|
+
|
|
22
|
+
### Step 1: State the Problem Clearly
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
Write your problem as a simple statement:
|
|
26
|
+
|
|
27
|
+
"Users are not completing checkout"
|
|
28
|
+
"Our API is too slow"
|
|
29
|
+
"Developers don't write tests"
|
|
30
|
+
"Customers are churning"
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
### Step 2: List Your Assumptions
|
|
34
|
+
|
|
35
|
+
Everything you believe to be true about the problem:
|
|
36
|
+
|
|
37
|
+
```
|
|
38
|
+
Problem: "Users are not completing checkout"
|
|
39
|
+
|
|
40
|
+
Assumptions:
|
|
41
|
+
1. Users WANT to complete checkout
|
|
42
|
+
2. The checkout flow is too LONG
|
|
43
|
+
3. Users need MORE payment options
|
|
44
|
+
4. PRICE is the main barrier
|
|
45
|
+
5. Users TRUST our site
|
|
46
|
+
6. Mobile experience is GOOD ENOUGH
|
|
47
|
+
7. Users FOUND the right product
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
### Step 3: Invert Each Assumption
|
|
51
|
+
|
|
52
|
+
| Original | Inverted | Exploration |
|
|
53
|
+
|----------|----------|-------------|
|
|
54
|
+
| Users want to complete | Users DON'T want to complete | Maybe cart = wishlist, not intent |
|
|
55
|
+
| Checkout is too long | Checkout is too SHORT | Missing trust signals? No confirmation? |
|
|
56
|
+
| Need more options | Need FEWER options | Decision paralysis? |
|
|
57
|
+
| Price is barrier | Price is NOT barrier | Shipping? Trust? Uncertainty? |
|
|
58
|
+
| Users trust us | Users DON'T trust us | New visitors? No reviews shown? |
|
|
59
|
+
| Mobile is good enough | Mobile is TERRIBLE | Test on real devices! |
|
|
60
|
+
| Found right product | Found WRONG product | Are they buying to try? |
|
|
61
|
+
|
|
62
|
+
### Step 4: Explore the Most Promising
|
|
63
|
+
|
|
64
|
+
Pick 2-3 inversions that resonate:
|
|
65
|
+
|
|
66
|
+
```
|
|
67
|
+
Most promising: "Cart = wishlist, not purchase intent"
|
|
68
|
+
|
|
69
|
+
Evidence:
|
|
70
|
+
- Average cart age is 3 days
|
|
71
|
+
- Users add 5 items, buy 1
|
|
72
|
+
- No "save for later" option
|
|
73
|
+
|
|
74
|
+
New approach:
|
|
75
|
+
- Add "Save for Later" prominently
|
|
76
|
+
- Only push checkout when behavior shows intent
|
|
77
|
+
- Send reminders for wishlisted items
|
|
78
|
+
- Reframe cart as "Your Collection"
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## Inversion Templates
|
|
84
|
+
|
|
85
|
+
### For Product Problems
|
|
86
|
+
|
|
87
|
+
| Assumption | Inversion Question |
|
|
88
|
+
|------------|-------------------|
|
|
89
|
+
| Users need this feature | What if this feature makes things worse? |
|
|
90
|
+
| More features = more value | What if fewer features = more value? |
|
|
91
|
+
| Users want control | What if users want automation? |
|
|
92
|
+
| Fast is better | What if slow is better? |
|
|
93
|
+
| Users know what they want | What if users don't know? |
|
|
94
|
+
|
|
95
|
+
### For Technical Problems
|
|
96
|
+
|
|
97
|
+
| Assumption | Inversion Question |
|
|
98
|
+
|------------|-------------------|
|
|
99
|
+
| This is a performance problem | What if it's a UX problem? |
|
|
100
|
+
| We need more servers | What if we need fewer requests? |
|
|
101
|
+
| The algorithm is wrong | What if the input is wrong? |
|
|
102
|
+
| We need real-time | What if eventual is fine? |
|
|
103
|
+
| This is a database issue | What if it's a caching issue? |
|
|
104
|
+
|
|
105
|
+
### For Process Problems
|
|
106
|
+
|
|
107
|
+
| Assumption | Inversion Question |
|
|
108
|
+
|------------|-------------------|
|
|
109
|
+
| We need more meetings | What if we need fewer meetings? |
|
|
110
|
+
| We need better documentation | What if we need less documentation? |
|
|
111
|
+
| We need more planning | What if we need less planning? |
|
|
112
|
+
| We need more people | What if we need fewer people? |
|
|
113
|
+
| We need to move faster | What if we need to slow down? |
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
## Example: API Performance
|
|
118
|
+
|
|
119
|
+
### Original Problem
|
|
120
|
+
"Our API is too slow (500ms average response time)"
|
|
121
|
+
|
|
122
|
+
### Assumptions
|
|
123
|
+
1. 500ms is too slow
|
|
124
|
+
2. Users notice the latency
|
|
125
|
+
3. The bottleneck is in our code
|
|
126
|
+
4. We need to optimize the database
|
|
127
|
+
5. Caching will help
|
|
128
|
+
|
|
129
|
+
### Inversions
|
|
130
|
+
|
|
131
|
+
| Assumption | Inversion | Insight |
|
|
132
|
+
|------------|-----------|---------|
|
|
133
|
+
| 500ms is too slow | 500ms is acceptable | Check: Do users actually complain? |
|
|
134
|
+
| Users notice | Users DON'T notice | Perception ≠ reality; test with users |
|
|
135
|
+
| Bottleneck is our code | Bottleneck is ELSEWHERE | Network latency? Client rendering? |
|
|
136
|
+
| Need DB optimization | DB is fine | Profile first; maybe it's JSON serialization |
|
|
137
|
+
| Caching will help | Caching will NOT help | What if requests are unique? |
|
|
138
|
+
|
|
139
|
+
### Discovery
|
|
140
|
+
After profiling: 400ms was JSON serialization, not database!
|
|
141
|
+
Solution: Switch serializer, 50ms response time.
|
|
142
|
+
The "database optimization" assumption would have wasted weeks.
|
|
143
|
+
|
|
144
|
+
---
|
|
145
|
+
|
|
146
|
+
## Warning Signs You Need Inversion
|
|
147
|
+
|
|
148
|
+
- "Everyone knows that..."
|
|
149
|
+
- "We've always done it this way"
|
|
150
|
+
- "That's just how it works"
|
|
151
|
+
- "Users expect..."
|
|
152
|
+
- "Best practice says..."
|
|
153
|
+
- You've been stuck for > 1 hour
|
|
154
|
+
|
|
155
|
+
---
|
|
156
|
+
|
|
157
|
+
## Practice Exercise
|
|
158
|
+
|
|
159
|
+
### Your Problem
|
|
160
|
+
Write it here:
|
|
161
|
+
> _______________________________________________
|
|
162
|
+
|
|
163
|
+
### Your Assumptions (list 5)
|
|
164
|
+
1. _______________________________________________
|
|
165
|
+
2. _______________________________________________
|
|
166
|
+
3. _______________________________________________
|
|
167
|
+
4. _______________________________________________
|
|
168
|
+
5. _______________________________________________
|
|
169
|
+
|
|
170
|
+
### Inversions
|
|
171
|
+
| # | Inversion | Worth exploring? |
|
|
172
|
+
|---|-----------|-----------------|
|
|
173
|
+
| 1 | What if... | |
|
|
174
|
+
| 2 | What if... | |
|
|
175
|
+
| 3 | What if... | |
|
|
176
|
+
| 4 | What if... | |
|
|
177
|
+
| 5 | What if... | |
|
|
178
|
+
|
|
179
|
+
### Most Promising
|
|
180
|
+
Pick one and explore deeply:
|
|
181
|
+
> _______________________________________________
|
|
182
|
+
|
|
183
|
+
---
|
|
184
|
+
|
|
185
|
+
## Quick Reference
|
|
186
|
+
|
|
187
|
+
```
|
|
188
|
+
INVERSION IN 30 SECONDS:
|
|
189
|
+
|
|
190
|
+
1. What do I believe is true?
|
|
191
|
+
→ "${assumption}"
|
|
192
|
+
|
|
193
|
+
2. What if the opposite is true?
|
|
194
|
+
→ "What if ${NOT assumption}?"
|
|
195
|
+
|
|
196
|
+
3. What would that change?
|
|
197
|
+
→ "If that's true, then..."
|
|
198
|
+
|
|
199
|
+
4. Is there evidence for the inversion?
|
|
200
|
+
→ "Let me check..."
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
---
|
|
204
|
+
|
|
205
|
+
> **Remember:** Inversion doesn't mean the opposite is true. It means the opposite is worth exploring. Some inversions will be dead ends; that's okay. One breakthrough inversion pays for all the dead ends.
|