@musashishao/agent-kit 1.0.0 → 1.1.0

package/.agent/skills/problem-solving/meta-pattern-recognition.md

@@ -0,0 +1,313 @@
+---
+name: meta-pattern-recognition
+parent: problem-solving
+description: Spot patterns appearing in 3+ domains to find universal principles worth extracting.
+---
+
+# Meta-Pattern Recognition
+
+> Universal truths hide at the intersection of unrelated domains.
+
+## When to Use
+
+- Solving a problem that exists in many fields
+- Looking for battle-tested principles
+- Want to leverage cross-domain wisdom
+- Need a higher-level perspective
+
+---
+
+## The Process
+
+### Step 1: Identify the Core Challenge
+
+Abstract your problem to its essence:
+
+```
+Specific: "Our codebase has too much tech debt"
+Abstract: "How do you manage accumulating problems 
+          that are easy to ignore?"
+
+Specific: "Users don't return after signup"
+Abstract: "How do you create lasting engagement 
+          from initial interaction?"
+
+Specific: "Our deploys are risky"
+Abstract: "How do you make dangerous operations 
+          safe and reversible?"
+```
+
+### Step 2: Find 3+ Domains with Similar Challenge
+
+```
+Challenge: "Managing accumulating problems 
+           that are easy to ignore"
+
+Similar in other domains:
+1. Physical infrastructure: Building maintenance
+2. Personal health: Ignored minor symptoms
+3. Finance: Compound debt/interest
+4. Ecology: Environmental degradation
+5. Relationships: Unresolved conflicts
+```
+
+### Step 3: Extract Patterns from Each Domain
+
+**Domain 1: Building Maintenance**
+```
+Observations:
+├── Small cracks become structural failures
+├── Prevention is 10x cheaper than repair
+├── Regular inspections catch early
+├── Deferred maintenance compounds
+└── "Emergency repairs" cost premium
+```
+
+**Domain 2: Personal Health**
+```
+Observations:
+├── Minor symptoms become chronic conditions
+├── Regular checkups catch early
+├── Health "debt" accumulates invisibly
+├── Crisis intervention is expensive
+└── Preventive care is undervalued
+```
+
+**Domain 3: Compound Finance**
+```
+Observations:
+├── Interest compounds exponentially
+├── Minimum payments don't reduce principal
+├── Snowball method: pay smallest first
+├── Visualization motivates action
+└── Avoiding new debt while paying old
+```
+
+**Domain 4: Ecology**
+```
+Observations:
+├── Degradation invisible until tipping point
+├── Restoration harder than prevention
+├── Systems are interconnected
+├── Small actions multiply over time
+└── Monitoring is essential
+```
+
+### Step 4: Find Universal Patterns
+
+| Pattern | Building | Health | Finance | Ecology | UNIVERSAL |
+|---------|----------|--------|---------|---------|-----------|
+| Growth | Compound | Compound | Compound | Compound | **Exponential when ignored** |
+| Cost | 10x repair | 10x crisis | High interest | Restoration | **Prevention << Cure** |
+| Visibility | Hidden | Hidden | Hidden | Hidden | **Invisible accumulation** |
+| Solution | Inspect | Checkup | Track | Monitor | **Regular inspection** |
+| System | Connected | Connected | Connected | Connected | **Interconnection cascades** |
+
+### Step 5: Apply Universal Patterns
+
+```
+Apply to tech debt:
+
+PATTERN: Exponential growth when ignored
+→ Track debt "age" - older = higher priority
+→ Interest rate metaphor for severity
+
+PATTERN: Prevention << Cure (10x+)
+→ Code review standards prevent debt creation
+→ "Boy scout rule": Leave cleaner than found
+→ Invest in prevention tooling
+
+PATTERN: Invisible accumulation until crisis
+→ Make debt visible: Dashboard, metrics
+→ Regular "debt review" meetings
+→ Alert when debt threshold exceeded
+
+PATTERN: Regular inspection is key
+→ Automated code quality scans
+→ Quarterly tech debt audits
+→ Part of sprint planning
+
+PATTERN: Interconnection causes cascades
+→ Map dependencies
+→ Prioritize shared code/library debt
+→ Isolate risky areas
+```
+
+---
+
+## Common Universal Patterns
+
+### The Compound Effect
+**Appears in:** Finance, health, habits, tech debt, relationships
+
+```
+Pattern: Small, consistent actions compound over time
+         Neglect also compounds over time
+
+Apply:
+├── Small daily improvements
+├── Early detection of problems
+├── Track metrics over time
+└── Make progress visible
+```
+
+### The Pareto Principle (80/20)
+**Appears in:** Economics, software bugs, productivity, sales
+
+```
+Pattern: 80% of effects come from 20% of causes
+
+Apply:
+├── Identify the vital few
+├── Focus resources on highest impact
+├── Eliminate the trivial many
+└── Regularly re-assess the 20%
+```
+
+### The Feedback Loop
+**Appears in:** Biology, climate, markets, social media
+
+```
+Pattern: Outputs become inputs, amplifying or dampening
+
+Apply:
+├── Design positive feedback for good behaviors
+├── Break negative feedback loops
+├── Fast feedback enables correction
+└── Delayed feedback causes over/under-correction
+```
+
+### The Network Effect
+**Appears in:** Phones, social networks, marketplaces, languages
+
+```
+Pattern: Value increases exponentially with users
+
+Apply:
+├── Early users are most important
+├── Reduce friction for adoption
+├── Make sharing valuable
+└── Critical mass changes everything
+```
+
+### Antifragility
+**Appears in:** Biology, economics, systems design, careers
+
+```
+Pattern: Some things gain from disorder up to a point
+
+Apply:
+├── Build systems that improve under stress
+├── Expose to small stressors (chaos engineering)
+├── Avoid fragile optimization
+└── Maintain slack/redundancy
+```
+
+---
+
+## Pattern Recognition Template
+
+```
+CHALLENGE: [Abstract your problem]
+
+DOMAIN 1: [Domain name]
+├── Observation 1
+├── Observation 2
+└── Observation 3
+
+DOMAIN 2: [Domain name]
+├── Observation 1
+├── Observation 2
+└── Observation 3
+
+DOMAIN 3: [Domain name]
+├── Observation 1
+├── Observation 2
+└── Observation 3
+
+UNIVERSAL PATTERN:
+[What appears in all 3+ domains?]
+
+APPLY TO MY PROBLEM:
+├── Applies as: [How it translates]
+├── Action: [What to do]
+└── Measure: [How to track]
+```
+
+---
+
+## Practice Exercise
+
+### Your Challenge (abstracted):
+> _______________________________________________
+
+### Domain 1:
+> Name: _______________________________________________
+> How they solve it: _______________________________________________
+
+### Domain 2:
+> Name: _______________________________________________
+> How they solve it: _______________________________________________
+
+### Domain 3:
+> Name: _______________________________________________
+> How they solve it: _______________________________________________
+
+### Common Pattern Across All:
+> _______________________________________________
+
+### Application to Your Problem:
+> _______________________________________________
+
+---
+
+## Domain Suggestions by Problem Type
+
+| Your Problem About... | Look At These Domains |
+|----------------------|----------------------|
+| Growth | Biology, finance, viruses, cities |
+| Trust | Marriage, banking, diplomacy, medicine |
+| Coordination | Orchestras, military, sports, flocks |
+| Resilience | Ecosystems, immune systems, infrastructure |
+| Learning | Children, athletes, craftsmen, AI |
+| Scale | Logistics, nature, franchises, infrastructure |
+| Quality | Luxury brands, surgery, aviation, food |
+| Speed | Emergency services, racing, journalism |
+
+---
+
+## Quick Reference
+
+```
+PATTERN RECOGNITION IN 60 SECONDS:
+
+1. Abstract your problem:
+   → "I'm really solving the problem of..."
+
+2. Find analogs:
+   → "What other fields solve this?"
+   → Pick 3 very different domains
+
+3. Extract what each does:
+   → "In [domain], they handle this by..."
+
+4. Find the common thread:
+   → "All of them do [pattern]"
+
+5. Apply to your context:
+   → "In my case, that means..."
+```
+
+---
+
+## Pro Tips
+
+- The more distant the domain, the more surprising the insight
+- Look at both successes AND failures
+- Ancient wisdom often contains patterns
+- Nature has solved most problems already
+- If 3 domains converge, the pattern is likely true
+
+---
+
+> **Remember:** You're not looking for analogies—you're looking for universal truths. If a pattern appears in biology, economics, AND social systems, it's probably a fundamental principle worth applying.

package/.agent/skills/problem-solving/scale-game.md

@@ -0,0 +1,300 @@
+---
+name: scale-game
+parent: problem-solving
+description: Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths hidden at normal scales.
+---
+
+# Scale Game
+
+> What breaks at 1000x? What's revealed at 0.001x?
+
+## When to Use
+
+- Need to stress-test assumptions
+- Want to find hidden constraints
+- Validating architecture decisions
+- Looking for edge cases
+- Checking if solution is robust
+
+---
+
+## The Process
+
+### Step 1: Identify Scalable Variables
+
+What can you scale up or down?
+
+```
+System: E-commerce checkout
+
+Scalable variables:
+├── Users: concurrent shoppers
+├── Orders: transactions per day
+├── Items: products in catalog
+├── Cart size: items per order
+├── Locations: geographic regions
+├── Time: seconds to checkout
+└── Price: value per transaction
+```
+
+### Step 2: Scale Up (1000x)
+
+Take each variable to extreme scale:
+
+```
+Current: 100 orders/day
+At 1000x: 100,000 orders/day
+
+WHAT BREAKS?
+├── Database: Single instance can't handle
+├── Inventory: Race conditions on popular items  
+├── Payments: Gateway rate limits hit
+├── Emails: Confirmation emails rate-limited
+├── Support: 1000x tickets
+
+WHAT'S REVEALED?
+├── No caching strategy exists
+├── Inventory system is synchronous
+├── No queue for async operations
+├── Single point of failure in payments
+└── Monitoring doesn't alert until crash
+```
+
+### Step 3: Scale Down (0.001x)
+
+```
+At 0.001x: 0.1 orders/day (1 order every 10 days)
+
+WHAT BREAKS?
+├── Sessions: Cart expires before purchase
+├── Data: Prices/availability become stale
+├── Engagement: Users forget they have cart
+├── Economics: Fixed costs don't scale down
+
+WHAT'S REVEALED?
+├── Need re-engagement for long cycles
+├── "Save cart" feature becomes critical
+├── Price guarantee for saved items
+├── Different UX for low-frequency users
+└── Batch processing inefficient
+```
+
+### Step 4: Extreme Dimensions
+
+Explore time, speed, size extremes:
+
+```
+TIME EXTREMES:
+┌─────────────────────────────────────────────────────────┐
+│ What if checkout took 1 SECOND total?                  │
+├─────────────────────────────────────────────────────────┤
+│ → Must pre-authorize everything                        │
+│ → One-click only, saved payment                        │
+│ → No real-time inventory check possible                │
+│ → Trust over verification                              │
+└─────────────────────────────────────────────────────────┘
+
+┌─────────────────────────────────────────────────────────┐
+│ What if checkout took 1 WEEK?                          │
+├─────────────────────────────────────────────────────────┤
+│ → Multi-session persistence                            │
+│ → Approval workflows (enterprise)                      │
+│ → Price/availability guarantees                        │
+│ → Multiple stakeholder access                          │
+│ → Robust save/resume                                   │
+└─────────────────────────────────────────────────────────┘
+```
+
+---
+
+## Scale Game Template
+
+### Variable Matrix
+
+| Variable | Current | 1000x | 0.001x | Insight |
+|----------|---------|-------|--------|---------|
+| Users | 1K | 1M | 1 | |
+| Data size | 1GB | 1TB | 1MB | |
+| Latency | 100ms | 100s | 0.1ms | |
+| Requests/sec | 10 | 10K | 0.01 | |
+| Team size | 10 | 10K | 1 | |
+| Time to deliver | 1 week | 1000 weeks | 1 hour | |
+
+### Time Dimension
+
+| Scenario | What Changes? |
+|----------|---------------|
+| 1000x faster (instant) | |
+| 1000x slower (ages) | |
+| Event happens once | |
+| Event happens constantly | |
+
+### Size Dimension
+
+| Scenario | What Changes? |
+|----------|---------------|
+| 1000x larger | |
+| 1000x smaller | |
+| Single item | |
+| Infinite items | |
+
+---
+
+## Example: API Design
+
+### Problem
+Design a user search API
+
+### Scale Analysis
+
+**SCALE UP: 1M users**
+```
+Current: 10K users, search by name
+
+At 1M users:
+├── Full-text search on database fails
+├── Need: Elasticsearch/Algolia
+├── Need: Result pagination (not all)
+├── Need: Caching of popular searches
+├── Need: Rate limiting
+└── Need: Async indexing
+
+INSIGHT: Design for search engine from start
+```
+
+**SCALE DOWN: 10 users**
+```
+At 10 users:
+├── Full-text search is overkill
+├── Simple filter works
+├── No pagination needed
+├── No caching needed
+└── Direct database query fine
+
+INSIGHT: Over-engineering is real
+```
+
+**SCALE TIME: Search in 1ms**
+```
+At 1ms response:
+├── Must be pre-computed
+├── Must be local (no network)
+├── Must fit in memory
+├── No database round-trip
+
+INSIGHT: Need edge caching for speed
+```
+
+**SCALE: Infinite concurrent searches**
+```
+At infinite concurrent:
+├── Stateless required
+├── Horizontal scaling
+├── Load balancing
+├── No shared state
+
+INSIGHT: Stateless from day 1
+```
+
+### Final Design Decisions
+Based on scale analysis:
+1. Use Elasticsearch (for 1M scale)
+2. Add result caching (for speed)
+3. Keep API stateless (for concurrency)
+4. Add pagination from start (for large results)
+5. Rate limit per user (for protection)
+
+---
+
+## Scale Thinking Shortcuts
+
+### "What breaks at 1000x?"
+Reveals: scalability issues, bottlenecks, single points of failure
+
+### "What breaks at 0.001x?"
+Reveals: overhead, minimum viable requirements, edge cases
+
+### "What if it's instant?"
+Reveals: async vs sync decisions, caching needs
+
+### "What if it takes a year?"
+Reveals: state management, persistence needs
+
+### "What if there's only one?"
+Reveals: over-engineering, unnecessary abstraction
+
+### "What if there's infinite?"
+Reveals: resource limits, throttling needs
+
+---
+
+## Practice Exercise
+
+### Your System:
+> _______________________________________________
+
+### Variables to Scale:
+1. _______________________________________________
+2. _______________________________________________
+3. _______________________________________________
+
+### Scale Up (1000x)
+| Variable | At 1000x | What Breaks? | What's Revealed? |
+|----------|----------|--------------|-----------------|
+| | | | |
+| | | | |
+| | | | |
+
+### Scale Down (0.001x)
+| Variable | At 0.001x | What Breaks? | What's Revealed? |
+|----------|-----------|--------------|-----------------|
+| | | | |
+| | | | |
+| | | | |
+
+### Time Extremes
+| If instant... | If takes a year... |
+|---------------|-------------------|
+| | |
+
+### Key Insights:
+1. _______________________________________________
+2. _______________________________________________
+3. _______________________________________________
+
+---
+
+## Quick Reference
+
+```
+SCALE GAME IN 30 SECONDS:
+
+1. Pick a variable (users, data, speed, time)
+
+2. Scale UP 1000x:
+   → "At 1000x [variable], what breaks?"
+
+3. Scale DOWN 0.001x:
+   → "At 0.001x [variable], what breaks?"
+
+4. Extract insight:
+   → "This reveals that we need..."
+
+5. Apply to current design:
+   → "So we should change..."
+```
+
+---
+
+## Warning Signs
+
+You need Scale Game when you hear:
+- "That'll never happen"
+- "We'll worry about scale later"
+- "This is just a prototype"
+- "Our users won't do that"
+- "We only have X users now"
+
+---
+
+> **Remember:** Scale Game isn't about predicting the future. It's about stress-testing your assumptions. The insights from extremes often reveal the right design for normal scales.