refactor: split emergent-patterns into focused problem-solving skills

**Restructure:**
- Split detecting-emergent-patterns (216 lines) into 5 focused skills (~60 lines each)
- Move tracing-lineages to skills/research/ (better category fit)
- Create skills/problem-solving/ category

**New problem-solving skills:**
- simplification-cascades: Find one insight that eliminates multiple components
- collision-zone-thinking: Force unrelated concepts together for breakthroughs
- meta-pattern-recognition: Spot patterns in 3+ domains
- inversion-exercise: Flip assumptions to reveal alternatives
- scale-game: Test at extremes to find fundamental limits
- when-stuck: Dispatch skill that maps stuck-symptoms to techniques

**Improvements:**
- Symptom-based when_to_use (what you'd actually think/feel)
- Quick reference tables for rapid scanning
- Pattern-based triggers (not exact phrase matching)
- Cross-references from brainstorming for discoverability

Each skill now: scannable in 30 seconds, applicable immediately, focused on one technique.

skills/problem-solving/meta-pattern-recognition/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: Meta-Pattern Recognition
+description: Spot patterns appearing in 3+ domains to find universal principles
+when_to_use: Same issue in different parts of codebase. Pattern feels familiar across projects. "Haven't I solved this before?" Different teams solving similar problems. Recurring solution shapes.
+version: 1.0.0
+---
+
+# Meta-Pattern Recognition
+
+## Overview
+
+When the same pattern appears in 3+ domains, it's probably a universal principle worth extracting.
+
+**Core principle:** Find patterns in how patterns emerge.
+
+## Quick Reference
+
+| Pattern Appears In | Abstract Form | Where Else? |
+|-------------------|---------------|-------------|
+| CPU/DB/HTTP/DNS caching | Store frequently-accessed data closer | LLM prompt caching, CDN |
+| Layering (network/storage/compute) | Separate concerns into abstraction levels | Architecture, organization |
+| Queuing (message/task/request) | Decouple producer from consumer with buffer | Event systems, async processing |
+| Pooling (connection/thread/object) | Reuse expensive resources | Memory management, resource governance |
+
+## Process
+
+1. **Spot repetition** - See same shape in 3+ places
+2. **Extract abstract form** - Describe independent of any domain
+3. **Identify variations** - How does it adapt per domain?
+4. **Check applicability** - Where else might this help?
+
+## Example
+
+**Pattern spotted:** Rate limiting in API throttling, traffic shaping, circuit breakers, admission control
+
+**Abstract form:** Bound resource consumption to prevent exhaustion
+
+**Variation points:** What resource, what limit, what happens when exceeded
+
+**New application:** LLM token budgets (same pattern - prevent context window exhaustion)
+
+## Red Flags You're Missing Meta-Patterns
+
+- "This problem is unique" (probably not)
+- Multiple teams independently solving "different" problems identically
+- Reinventing wheels across domains
+- "Haven't we done something like this?" (yes, find it)
+
+## Remember
+
+- 3+ domains = likely universal
+- Abstract form reveals new applications
+- Variations show adaptation points
+- Universal patterns are battle-tested