@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.

@@ -0,0 +1,556 @@
1
+ ---
2
+ name: problem-solving
3
+ description: Advanced problem-solving frameworks for complex challenges. 6 techniques for when you're stuck, need creative solutions, or want to think differently.
4
+ allowed-tools: Read, Write, Edit
5
+ ---
6
+
7
+ # Problem-Solving Frameworks
8
+
9
+ > Think differently. Solve creatively. Break through blocks.
10
+
11
+ ## 📋 Quick Reference
12
+
13
+ | Framework | When to Use | Key Question |
14
+ |-----------|-------------|--------------|
15
+ | [When Stuck](#1-when-stuck-dispatcher) | Don't know which technique | "What type of stuck am I?" |
16
+ | [Inversion](#2-inversion-exercise) | Assumptions blocking you | "What if the opposite were true?" |
17
+ | [Collision Zone](#3-collision-zone-thinking) | Need creative breakthrough | "What if we treated X like Y?" |
18
+ | [Scale Game](#4-scale-game) | Hidden constraints | "What happens at 1000x?" |
19
+ | [Pattern Recognition](#5-meta-pattern-recognition) | Complex systems | "What patterns appear across domains?" |
20
+ | [Simplification](#6-simplification-cascades) | Overcomplicated solution | "What one insight eliminates everything?" |
21
+
22
+ ---
23
+
24
+ ## 1. When Stuck (Dispatcher)
25
+
26
+ > Use this first to route to the right technique.
27
+
28
+ ### Stuck Type Assessment
29
+
30
+ ```
31
+ What type of stuck are you?
32
+
33
+ ┌─────────────────────────────────────────────────────────────┐
34
+ │ 1. "I don't know where to start" │
35
+ │ → Use INVERSION: Start from the end, work backwards │
36
+ ├─────────────────────────────────────────────────────────────┤
37
+ │ 2. "I've tried everything, nothing works" │
38
+ │ → Use COLLISION ZONE: Combine unrelated concepts │
39
+ ├─────────────────────────────────────────────────────────────┤
40
+ │ 3. "The solution is too complex" │
41
+ │ → Use SIMPLIFICATION: Find the one insight that changes │
42
+ │ everything │
43
+ ├─────────────────────────────────────────────────────────────┤
44
+ │ 4. "I can't see the full picture" │
45
+ │ → Use PATTERN RECOGNITION: Find patterns across domains │
46
+ ├─────────────────────────────────────────────────────────────┤
47
+ │ 5. "My assumptions might be wrong" │
48
+ │ → Use INVERSION: Flip every assumption │
49
+ ├─────────────────────────────────────────────────────────────┤
50
+ │ 6. "I need to validate my approach" │
51
+ │ → Use SCALE GAME: Test at extreme scales │
52
+ └─────────────────────────────────────────────────────────────┘
53
+ ```
54
+
55
+ ### Quick Unstuck Protocol
56
+
57
+ 1. **Name the block:** Write one sentence about why you're stuck
58
+ 2. **Categorize:** Match to stuck type above
59
+ 3. **Apply framework:** Use the recommended technique
60
+ 4. **Iterate:** If still stuck, try the next framework
61
+
62
+ ---
63
+
64
+ ## 2. Inversion Exercise
65
+
66
+ > "What if the opposite were true?"
67
+
68
+ ### When to Use
69
+ - Assumptions are blocking progress
70
+ - Conventional approaches have failed
71
+ - Need fresh perspective on old problem
72
+
73
+ ### The Process
74
+
75
+ #### Step 1: List Your Assumptions
76
+ ```
77
+ Problem: Users aren't completing checkout
78
+
79
+ Assumptions:
80
+ - Users want to complete checkout
81
+ - The checkout flow is too long
82
+ - Users need more payment options
83
+ - Price is the main barrier
84
+ ```
85
+
86
+ #### Step 2: Invert Each Assumption
87
+ ```
88
+ Inversions:
89
+ - What if users DON'T want to complete checkout?
90
+ → Are we pushing them too early?
91
+ → Is cart a wishlist, not purchase intent?
92
+
93
+ - What if checkout is TOO SHORT?
94
+ → Missing trust signals?
95
+ → No confirmation they're buying the right thing?
96
+
97
+ - What if users want FEWER options?
98
+ → Decision paralysis from too many choices?
99
+
100
+ - What if price ISN'T the barrier?
101
+ → Shipping? Trust? Uncertainty about product?
102
+ ```
103
+
104
+ #### Step 3: Explore Promising Inversions
105
+ ```
106
+ Most promising inversion:
107
+ "Cart is a wishlist, not purchase intent"
108
+
109
+ New approach:
110
+ - Add "Save for Later" prominently
111
+ - Only push checkout when browsing pattern shows intent
112
+ - Send reminder emails for wishlisted items
113
+ ```
114
+
115
+ ### Inversion Templates
116
+
117
+ | Original Assumption | Inversion Question |
118
+ |-------------------|-------------------|
119
+ | Users need X feature | What if X makes things worse? |
120
+ | This is a tech problem | What if this is a people problem? |
121
+ | More data will help | What if we have too much data? |
122
+ | Speed is important | What if slow is actually better? |
123
+ | Users want control | What if users want less decisions? |
124
+
125
+ ---
126
+
127
+ ## 3. Collision Zone Thinking
128
+
129
+ > "What if we treated X like Y?"
130
+
131
+ ### When to Use
132
+ - Need creative breakthrough
133
+ - Incremental improvements aren't enough
134
+ - Looking for innovation, not optimization
135
+
136
+ ### The Process
137
+
138
+ #### Step 1: Define Your Problem Space
139
+ ```
140
+ Problem: Onboarding new developers is slow (3 weeks)
141
+ Current solutions: Documentation, pairing, training
142
+ ```
143
+
144
+ #### Step 2: Pick Unrelated Domains
145
+ ```
146
+ Random domains:
147
+ - Video games
148
+ - Restaurant kitchens
149
+ - Airport security
150
+ - Theme parks
151
+ ```
152
+
153
+ #### Step 3: Force Collisions
154
+ ```
155
+ "What if onboarding was like a VIDEO GAME?"
156
+ ├── Levels: Progressive complexity, unlock new areas
157
+ ├── Quests: Small, clear objectives with rewards
158
+ ├── XP System: Track progress, celebrate milestones
159
+ ├── NPCs: Bot guides that answer questions
160
+ └── Multiplayer: Collaborative challenges with team
161
+
162
+ "What if onboarding was like AIRPORT SECURITY?"
163
+ ├── Clear checkpoints: Must pass each before next
164
+ ├── Fast lanes: Skip if you have experience
165
+ ├── Screening: Assess skills upfront, personalize path
166
+ └── Pre-check: Pre-work before first day
167
+ ```
168
+
169
+ #### Step 4: Extract Insights
170
+ ```
171
+ Winning insight from Video Games:
172
+ → Create "Developer Quest" system
173
+ - Day 1: Complete 3 quests (setup, first commit, code review)
174
+ - Week 1: Earn "Backend Badge" by completing module
175
+ - Instant feedback on progress
176
+ - Leaderboard for fun competition
177
+ ```
178
+
179
+ ### Collision Prompt Templates
180
+
181
+ ```
182
+ "What if [YOUR PROBLEM] worked like [RANDOM DOMAIN]?"
183
+
184
+ Fill in:
185
+ - What if user auth worked like a hotel check-in?
186
+ - What if code review worked like restaurant quality control?
187
+ - What if deployment worked like a rocket launch?
188
+ - What if bug fixing worked like detective work?
189
+ - What if documentation worked like a museum tour?
190
+ ```
191
+
192
+ ---
193
+
194
+ ## 4. Scale Game
195
+
196
+ > "What happens at 1000x? At 0.001x?"
197
+
198
+ ### When to Use
199
+ - Need to stress-test assumptions
200
+ - Want to find hidden constraints
201
+ - Validating architecture decisions
202
+ - Looking for edge cases
203
+
204
+ ### The Process
205
+
206
+ #### Step 1: Identify Variables to Scale
207
+ ```
208
+ System: E-commerce checkout
209
+
210
+ Scalable variables:
211
+ - Number of users
212
+ - Cart size
213
+ - Transaction frequency
214
+ - Product catalog size
215
+ - Geographic distribution
216
+ ```
217
+
218
+ #### Step 2: Scale Up (1000x)
219
+ ```
220
+ Current: 100 orders/day
221
+ At 1000x: 100,000 orders/day
222
+
223
+ What breaks?
224
+ ├── Database: Single Postgres won't handle
225
+ ├── Inventory: Race conditions on popular items
226
+ ├── Payments: Gateway rate limits hit
227
+ ├── Emails: Confirmation emails get rate limited
228
+ ├── Support: 1000x support tickets
229
+
230
+ What's revealed?
231
+ → We have no caching strategy
232
+ → Inventory system is synchronous
233
+ → No queuing for async operations
234
+ ```
235
+
236
+ #### Step 3: Scale Down (0.001x)
237
+ ```
238
+ At 0.001x: 0.1 orders/day (1 order every 10 days)
239
+
240
+ What's revealed?
241
+ ├── Session timeouts: Cart expires before purchase
242
+ ├── Stale data: Prices/availability change
243
+ ├── Engagement: Users forget they have cart
244
+ ├── Economics: Fixed costs don't scale down
245
+
246
+ Insights:
247
+ → Need re-engagement for long consideration cycles
248
+ → "Save cart" feature becomes critical
249
+ → Price guarantee for saved items
250
+ ```
251
+
252
+ #### Step 4: Extreme Dimensions
253
+ ```
254
+ What if checkout took 1 SECOND total?
255
+ → Must pre-authorize everything
256
+ → One-click only works with saved info
257
+ → No real-time inventory check possible
258
+
259
+ What if checkout took 1 WEEK?
260
+ → Multi-session persistence required
261
+ → Approval workflows (enterprise sales)
262
+ → Price/availability guarantees needed
263
+ → Reminders and notifications
264
+ ```
265
+
266
+ ### Scale Game Template
267
+
268
+ | Variable | Current | 1000x | 0.001x | Insight |
269
+ |----------|---------|-------|--------|---------|
270
+ | Users | 1K | 1M | 1 | ? |
271
+ | Requests/sec | 10 | 10K | 0.01 | ? |
272
+ | Data size | 1GB | 1TB | 1MB | ? |
273
+ | Latency | 100ms | 100s | 0.1ms | ? |
274
+
275
+ ---
276
+
277
+ ## 5. Meta-Pattern Recognition
278
+
279
+ > "What patterns appear across 3+ domains?"
280
+
281
+ ### When to Use
282
+ - Solving a problem that exists in many fields
283
+ - Looking for universal principles
284
+ - Want to leverage cross-domain wisdom
285
+
286
+ ### The Process
287
+
288
+ #### Step 1: Identify the Core Challenge
289
+ ```
290
+ Core challenge: Managing technical debt
291
+ ```
292
+
293
+ #### Step 2: Find 3+ Domains with Similar Challenge
294
+ ```
295
+ Similar challenges in other domains:
296
+ 1. Physical infrastructure: Deferred building maintenance
297
+ 2. Personal health: Ignored minor health issues
298
+ 3. Finance: Compound interest on debt
299
+ 4. Ecology: Environmental degradation
300
+ ```
301
+
302
+ #### Step 3: Extract Patterns Across All
303
+ ```
304
+ Pattern Analysis:
305
+
306
+ Domain 1 - Building maintenance:
307
+ - Small issues become structural problems
308
+ - Prevention 10x cheaper than repair
309
+ - Regular inspection catch early
310
+
311
+ Domain 2 - Health:
312
+ - Minor symptoms become chronic conditions
313
+ - Regular checkups prevent major issues
314
+ - "Debt" accumulates invisibly
315
+
316
+ Domain 3 - Finance:
317
+ - Interest compounds exponentially
318
+ - Minimum payments don't reduce principal
319
+ - Snowball method: smallest first
320
+
321
+ Domain 4 - Ecology:
322
+ - Degradation invisible until tipping point
323
+ - Restoration harder than prevention
324
+ - Systems interconnected
325
+
326
+ UNIVERSAL PATTERNS:
327
+ ├── Exponential growth when ignored
328
+ ├── Prevention << Cure (10x or more)
329
+ ├── Invisible accumulation until crisis
330
+ ├── Regular inspection is key
331
+ └── Interconnection causes cascades
332
+ ```
333
+
334
+ #### Step 4: Apply Universal Patterns
335
+ ```
336
+ Apply to tech debt:
337
+
338
+ 1. Exponential growth
339
+ → Track debt age, older = higher priority
340
+
341
+ 2. Prevention << Cure
342
+ → Code review standards prevent debt
343
+ → "Boy scout rule": Leave code cleaner
344
+
345
+ 3. Invisible accumulation
346
+ → Make debt visible: Dashboard, metrics
347
+ → Regular "debt review" meetings
348
+
349
+ 4. Regular inspection
350
+ → Automated code quality checks
351
+ → Quarterly debt audits
352
+
353
+ 5. Cascading effects
354
+ → Map dependencies
355
+ → Prioritize shared code debt
356
+ ```
357
+
358
+ ### Pattern Template
359
+
360
+ | Domain 1 | Domain 2 | Domain 3 | UNIVERSAL PATTERN |
361
+ |----------|----------|----------|-------------------|
362
+ | Observation A1 | Observation A2 | Observation A3 | → Pattern A |
363
+ | Observation B1 | Observation B2 | Observation B3 | → Pattern B |
364
+
365
+ ---
366
+
367
+ ## 6. Simplification Cascades
368
+
369
+ > "What one insight eliminates multiple components?"
370
+
371
+ ### When to Use
372
+ - Solution feels overcomplicated
373
+ - Too many edge cases
374
+ - Architecture is getting messy
375
+ - Looking for elegant solutions
376
+
377
+ ### The Process
378
+
379
+ #### Step 1: Map Current Complexity
380
+ ```
381
+ Current feature: User permissions system
382
+
383
+ Components:
384
+ ├── Role definitions (5 files)
385
+ ├── Permission checks (23 places)
386
+ ├── Role assignment UI (3 screens)
387
+ ├── Role inheritance logic
388
+ ├── Permission cache
389
+ ├── Audit logging
390
+ └── Admin override system
391
+ ```
392
+
393
+ #### Step 2: Ask "What If" Questions
394
+ ```
395
+ Simplification questions:
396
+
397
+ 1. "What if there were only 2 roles?"
398
+ - Most systems really need: Admin vs Member
399
+ - 90% of role complexity is unused
400
+
401
+ 2. "What if permissions were at the resource level?"
402
+ - Instead of user → role → permission
403
+ - Just user → resource access
404
+
405
+ 3. "What if we removed inheritance?"
406
+ - Explicit > Implicit
407
+ - Copy permissions instead of inheriting
408
+ ```
409
+
410
+ #### Step 3: Find Cascade Effects
411
+ ```
412
+ Winning insight: "Only 2 roles needed"
413
+
414
+ Cascade effect:
415
+ ├── ELIMINATE: Role inheritance (not needed)
416
+ ├── ELIMINATE: Complex permission matrix
417
+ ├── SIMPLIFY: Role UI (dropdown instead of checkboxes)
418
+ ├── SIMPLIFY: Permission checks (isAdmin? helper)
419
+ ├── ELIMINATE: Most audit complexity
420
+ └── KEEP: Resource-level exceptions only
421
+
422
+ Complexity reduction: 7 components → 3
423
+ Code reduction: ~60%
424
+ Maintenance reduction: ~80%
425
+ ```
426
+
427
+ #### Step 4: Validate Simplification
428
+ ```
429
+ Validation questions:
430
+ - Does this cover 90% of use cases? → Yes
431
+ - What's lost? → Granular permission control
432
+ - Can we add back if needed? → Yes, progressively
433
+ - What's the migration path? → Map existing to 2 roles
434
+ ```
435
+
436
+ ### Simplification Patterns
437
+
438
+ | Complex Approach | Simple Alternative |
439
+ |-----------------|-------------------|
440
+ | Multiple inheritance | Composition/copying |
441
+ | Flexible schema | Fixed schema + extensions table |
442
+ | Real-time everything | Eventually consistent + refresh |
443
+ | Custom solution | Off-the-shelf + workarounds |
444
+ | Prevent all edge cases | Handle, log, and monitor |
445
+
446
+ ---
447
+
448
+ ## 7. Combining Frameworks
449
+
450
+ ### Sequential Combination
451
+
452
+ ```
453
+ Problem: Our API is too slow
454
+
455
+ 1. INVERSION: "What if slow is okay?"
456
+ → Insight: Users can tolerate 3s, not 300ms
457
+
458
+ 2. SCALE GAME: "What at 1000x requests?"
459
+ → Insight: Caching solves 90% of requests
460
+
461
+ 3. SIMPLIFICATION: "What one change helps most?"
462
+ → Insight: Add CDN, eliminate 10 optimization tickets
463
+
464
+ Final solution: CDN + Accept 3s for cache misses
465
+ Effort: 1 day instead of 2 weeks
466
+ ```
467
+
468
+ ### Parallel Combination
469
+
470
+ ```
471
+ Problem: User retention is dropping
472
+
473
+ Run all frameworks simultaneously:
474
+
475
+ INVERSION: "What if users SHOULD leave?"
476
+ → Maybe we're attracting wrong users
477
+
478
+ COLLISION: "What if our app was like a gym?"
479
+ → People sign up but don't come; need habit triggers
480
+
481
+ SCALE: "What at 1 user?"
482
+ → App feels empty without community
483
+
484
+ PATTERNS: "Retention in games, social, fitness"
485
+ → Progress tracking, social proof, streaks
486
+
487
+ SIMPLIFICATION: "One feature for retention?"
488
+ → Daily streak with reward = 40% retention boost
489
+ ```
490
+
491
+ ---
492
+
493
+ ## 8. Quick Reference Card
494
+
495
+ ```
496
+ ┌─────────────────────────────────────────────────────────────┐
497
+ │ PROBLEM-SOLVING QUICK REFERENCE │
498
+ ├─────────────────────────────────────────────────────────────┤
499
+ │ │
500
+ │ STUCK? → Ask: "What type of stuck am I?" │
501
+ │ │
502
+ │ INVERSION │
503
+ │ → Flip assumptions │
504
+ │ → "What if the opposite were true?" │
505
+ │ │
506
+ │ COLLISION ZONE │
507
+ │ → Force unrelated concepts together │
508
+ │ → "What if X worked like Y?" │
509
+ │ │
510
+ │ SCALE GAME │
511
+ │ → Test at 1000x and 0.001x │
512
+ │ → "What breaks? What's revealed?" │
513
+ │ │
514
+ │ PATTERN RECOGNITION │
515
+ │ → Find patterns in 3+ domains │
516
+ │ → "What universal principle applies?" │
517
+ │ │
518
+ │ SIMPLIFICATION │
519
+ │ → Find the one insight that changes everything │
520
+ │ → "What eliminates multiple components?" │
521
+ │ │
522
+ └─────────────────────────────────────────────────────────────┘
523
+ ```
524
+
525
+ ---
526
+
527
+ ## 9. Exercise: Practice Problem
528
+
529
+ ### Problem
530
+ > Our CI/CD pipeline takes 45 minutes. Developers complain it's too slow.
531
+
532
+ ### Apply Each Framework
533
+
534
+ **INVERSION:** What if 45 minutes is fine?
535
+ - Maybe the issue is unpredictable time, not length
536
+ - What if we ran builds in background?
537
+
538
+ **COLLISION:** What if CI was like a restaurant kitchen?
539
+ - Prep (tests) before service (deploy)
540
+ - Parallel stations (parallel jobs)
541
+ - Priority orders (urgent hotfixes)
542
+
543
+ **SCALE:** At 1000x commits/day?
544
+ - Queue would be infinite
545
+ - Need: Deduplication, priority, caching
546
+
547
+ **PATTERNS:** Build systems, cooking, manufacturing
548
+ - All use: Caching, parallelization, incremental work
549
+ - Toyota: Do smallest unit of work possible
550
+
551
+ **SIMPLIFICATION:** One change for 80% improvement?
552
+ - Cache unchanged steps = 30min → 10min
553
+
554
+ ---
555
+
556
+ > **Remember:** These frameworks are tools, not rules. Use them when stuck, combine them for complex problems, and develop your own variations. The goal is better thinking, not following a checklist.