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/architecture/detecting-emergent-patterns/SKILL.md

@@ -1,216 +0,0 @@
----
-name: Detecting Emergent Patterns
-description: Find breakthrough insights by forcing unrelated concepts together, detecting meta-patterns across domains, and discovering simplification cascades
-when_to_use: When stuck on complex problems. When searching for innovative solutions. When same issue appears in different domains. When complexity feels excessive. When conventional approaches aren't working. When seeking radical simplification.
-version: 1.0.0
----
-
-# Detecting Emergent Patterns
-
-## Overview
-
-Revolutionary insights often come from unexpected connections. This skill helps you force unrelated concepts together, recognize patterns across domains, and find simplifications that make hard problems easy.
-
-**Core principle:** The best solutions often come from collision-zone thinking - forcing concepts from different domains to interact.
-
-## Technique 1: Collision-Zone Thinking
-
-Force unrelated concepts together to discover emergent properties:
-
-**Process:**
-1. **Pick two unrelated concepts** from different domains
-2. **Force combination**: "What if we treated X like Y?"
-3. **Explore emergent properties**: What new capabilities appear?
-4. **Test validity**: Does the metaphor break? Where?
-
-**Example collisions:**
-- "What if we treated code like DNA?" → Genetic algorithms, mutation testing
-- "What if we treated services like lego bricks?" → Microservices, composable architecture
-- "What if we treated data like water?" → Data lakes, streaming, flow-based programming
-- "What if we treated requests like letters?" → Message queues, async processing
-
-**Document experiments:**
-```markdown
-## Collision Experiment: [Concept A] × [Concept B]
-
-**Forced combination:** What if we treated [A] like [B]?
-
-**Emergent properties:**
-- [New capability 1]
-- [New capability 2]
-
-**Where it works:** [Specific contexts]
-**Where it breaks:** [Limitations]
-**Insight gained:** [What we learned]
-```
-
-## Technique 2: Meta-Pattern Recognition
-
-Find patterns in how patterns emerge:
-
-**Look for:**
-- **Same shape, different domain**: Caching (CPU/DB/HTTP/DNS) - all same pattern
-- **Recurring solutions**: Layering, queuing, pooling, proxying appear everywhere
-- **Universal tensions**: Speed vs accuracy, simplicity vs features, cost vs performance
-- **Abstraction levels**: Physical → Logical → Virtual (appears in networking, storage, compute)
-
-**When you spot a pattern appearing in 3+ domains:**
-
-1. **Extract the abstract form** (independent of any domain)
-2. **Identify variation points** (how it adapts per domain)
-3. **Check applicability** (where else might this pattern help?)
-
-**Example:**
-```markdown
-## Meta-Pattern: Circuit Breaking
-
-**Appears in:**
-- Electrical: Circuit breakers prevent overload
-- Microservices: Circuit breaker pattern prevents cascade failures
-- Psychology: "Taking a break" prevents burnout
-- Economics: Trading halts prevent market crashes
-
-**Abstract form:** Monitor system, detect dangerous conditions, temporarily disconnect to prevent catastrophic failure, reconnect when safe
-
-**Variation points:** What triggers break, how long to wait, how to test if safe
-
-**New application:** Could apply to AI training (detect overfitting early, pause, adjust, resume)
-```
-
-## Technique 3: Simplification Cascades
-
-Find insights that dramatically reduce complexity:
-
-**Look for:**
-- **"If this is true, we don't need X, Y, or Z"** - One insight eliminates multiple components
-- **"Everything becomes a special case of..."** - Generalization that subsumes specifics
-- **"This replaces 10 techniques with one"** - Unifying approach
-
-**Red flags signaling simplification opportunity:**
-- Same concept implemented 5 different ways
-- Complex rules with many special cases
-- "We handle A, B, C, D differently" (maybe they're the same underneath?)
-- Excessive configuration options
-- Many if/else branches doing similar things
-
-**Cascade detection:**
-```markdown
-## Simplification: [Core Insight]
-
-**Replaces:**
-- [Technique 1 - no longer needed]
-- [Technique 2 - no longer needed]
-- [Technique 3 - no longer needed]
-
-**By realizing:** [The unifying insight]
-
-**Complexity reduction:** 10x (10 things → 1 thing)
-
-**Example:** "If we treat all inputs as streams, we don't need separate batch/real-time/file/network handlers - just different stream sources"
-```
-
-## Technique 4: Inversion Exercise
-
-Sometimes inverting assumptions reveals insights:
-
-**Process:**
-1. **List core assumptions** about the problem
-2. **Systematically invert each** ("what if the opposite were true?")
-3. **Explore implications** (what would we do differently?)
-4. **Find valid inversions** (which actually work in some context?)
-
-**Example inversions:**
-- Normal: "Cache to reduce latency" → Inverted: "Add latency to enable caching" (debouncing)
-- Normal: "Pull data when needed" → Inverted: "Push data before it's needed" (prefetching)
-- Normal: "Handle errors when they occur" → Inverted: "Make errors impossible" (type systems)
-
-## Technique 5: Scale Game
-
-See what breaks/survives at extreme scales:
-
-**Test at extremes:**
-- What if this was 1000x bigger? 1000x smaller?
-- What if this was instant? What if it took a year?
-- What if we had 1 user? 1 billion users?
-
-**Why it works:** Extremes expose fundamental truths hidden at normal scales
-
-**Example:**
-- "Handle errors" works at small scale
-- At 1B scale → "Make errors impossible" becomes necessary
-- Reveals: Type systems aren't "nice to have", they're "survival requirement at scale"
-
-## When Patterns Are Productive
-
-**Use emergent pattern detection when:**
-- Stuck on hard problems
-- Conventional solutions feel inadequate
-- Multiple domains showing similar issues
-- Complexity spiraling without clear path
-- Innovation needed, not optimization
-
-**Don't force it when:**
-- Simple solution already exists
-- Problem is straightforward
-- Domain-specific knowledge more valuable
-- Time-constrained execution needed
-
-## Red Flags - You're Missing Patterns
-
-- "This problem is unique" (probably not - similar patterns likely exist elsewhere)
-- Multiple teams solving "different" problems identically (maybe they're the same problem)
-- Growing list of special cases (maybe they're variations of one thing)
-- "We just need to handle one more scenario" (repeating forever = missing pattern)
-
-**All of these suggest: STOP. Look for the underlying pattern.**
-
-## Documentation Format
-
-```markdown
-## Pattern Discovery: [Name]
-
-**Recognition:** [What made you see this]
-
-**Domains observed:**
-1. [Domain 1 example]
-2. [Domain 2 example]
-3. [Domain 3 example]
-
-**Abstract pattern:** [Domain-independent description]
-
-**New application:** [Where else this could help]
-
-**Validation:** [How to test if pattern truly applies]
-```
-
-## Examples
-
-### Collision Success
-**Experiment:** "What if we treated logs like databases?"
-**Emergent property:** SQL queries over logs (Splunk, ELK)
-**Insight:** Structured data in disguise, just needs query language
-
-### Meta-Pattern
-**Pattern:** Rate limiting appears in: API throttling, traffic shaping, circuit breakers, admission control
-**Abstract form:** Bound resource consumption to prevent exhaustion
-**New application:** LLM token budgets (same pattern!)
-
-### Simplification Cascade
-**Insight:** "Treat everything as immutable data + transformations"
-**Eliminates:** Defensive copying, synchronization, cache invalidation, temporal coupling
-**Result:** Functional programming revolution
-
-### Inversion Win
-**Normal:** "Build features users want"
-**Inverted:** "Remove features users don't need"
-**Insight:** Sometimes subtraction >> addition (path to simplicity)
-
-## Remember
-
-- Best insights come from unexpected connections
-- Force concepts together deliberately
-- Pattern in 3+ domains suggests universal principle
-- Simplification cascades eliminate multiple problems at once
-- Inversion reveals hidden assumptions
-- Extremes expose fundamental truths
-- Document even failed experiments (they teach)

skills/architecture/preserving-productive-tensions/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: Preserving Productive Tensions
 description: Recognize when disagreements reveal valuable context, preserve multiple valid approaches instead of forcing premature resolution
-when_to_use: When multiple approaches have legitimate trade-offs. When stakeholders have conflicting valid priorities. When context determines which approach is better. During design when you're tempted to ask "which is best?" but both are good. When tensions reveal flexibility needs.
+when_to_use: Going back and forth between options. Both approaches seem equally good. Keep changing your mind. About to ask "which is better?" but sense both optimize for different things. Stakeholders want conflicting things (both valid).
 version: 1.0.0
 ---
 

skills/collaboration/brainstorming/SKILL.md

@@ -30,13 +30,13 @@ digraph brainstorming_modes {
 
     UNDERSTANDING -> EXPLORING [label="Have enough context to propose alternatives\n(gathered purpose, constraints, success criteria)"];
 
-    EXPLORING -> UNDERSTANDING [label="New constraints emerge\n(compliance, infrastructure, security, 'Oh I forgot to mention...')"];
+    EXPLORING -> UNDERSTANDING [label="Partner reveals new constraint\n(compliance requirement, infrastructure limit, security need, forgotten requirement)"];
 
     EXPLORING -> DESIGNING [label="Approach selected and validated\n(partner chose an approach, have all critical constraints)"];
 
-    DESIGNING -> UNDERSTANDING [label="Fundamental gaps revealed during validation\n(missing constraints, assumptions questioned)"];
+    DESIGNING -> UNDERSTANDING [label="Partner reveals fundamental gap\n(missing critical constraint, core assumption questioned)"];
 
-    DESIGNING -> EXPLORING [label="Need to compare alternatives\n(trade-offs significant, partner asks 'what are the options?')"];
+    DESIGNING -> EXPLORING [label="Need to reconsider approach\n(trade-offs too significant, partner questions approach)"];
 }
 ```
 
@@ -79,12 +79,14 @@ When your partner confirms (any affirmative response):
 
 ## Related Skills
 
+**When stuck at any point:**
+- Use skills/problem-solving/when-stuck to dispatch to right technique
+
 **During EXPLORING mode:**
 - When approaches have genuine trade-offs: skills/architecture/preserving-productive-tensions
-- When stuck or seeking innovation: skills/architecture/detecting-emergent-patterns
 
-**Before proposing changes:**
-- Understand why current approach exists: skills/architecture/tracing-knowledge-lineages
+**Before proposing changes to existing code:**
+- Understand why it exists: skills/research/tracing-knowledge-lineages
 
 ## Remember
 

skills/collaboration/executing-plans/SKILL.md

@@ -32,9 +32,9 @@ digraph executing_modes {
 
     REVIEWING -> EXECUTING [label="Plan is sound, no concerns\n(created TodoWrite, ready to start first batch)"];
 
-    REVIEWING -> BLOCKED [label="Plan has issues that prevent starting\n(missing info, unclear instructions, dependencies)"];
+    REVIEWING -> BLOCKED [label="Plan has critical gaps\n(missing information, unclear instructions, unmet dependencies)"];
 
-    EXECUTING -> BLOCKED [label="Hit a blocker mid-batch\n(missing dependency, test fails, unclear instruction)"];
+    EXECUTING -> BLOCKED [label="Cannot proceed with current task\n(dependency missing, test failing, instruction unclear)"];
 
     EXECUTING -> REPORTING [label="Batch completed successfully\n(all tasks done, verifications pass)"];
 

skills/problem-solving/collision-zone-thinking/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: Collision-Zone Thinking
+description: Force unrelated concepts together to discover emergent properties - "What if we treated X like Y?"
+when_to_use: Can't find approach that fits your problem. Conventional solutions feel inadequate. Need innovative solution. Stuck thinking inside one domain. Want breakthrough, not incremental improvement.
+version: 1.0.0
+---
+
+# Collision-Zone Thinking
+
+## Overview
+
+Revolutionary insights come from forcing unrelated concepts to collide. Treat X like Y and see what emerges.
+
+**Core principle:** Deliberate metaphor-mixing generates novel solutions.
+
+## Quick Reference
+
+| Stuck On | Try Treating As | Might Discover |
+|----------|-----------------|----------------|
+| Code organization | DNA/genetics | Mutation testing, evolutionary algorithms |
+| Service architecture | Lego bricks | Composable microservices, plug-and-play |
+| Data management | Water flow | Streaming, data lakes, flow-based systems |
+| Request handling | Postal mail | Message queues, async processing |
+| Error handling | Circuit breakers | Fault isolation, graceful degradation |
+
+## Process
+
+1. **Pick two unrelated concepts** from different domains
+2. **Force combination**: "What if we treated [A] like [B]?"
+3. **Explore emergent properties**: What new capabilities appear?
+4. **Test boundaries**: Where does the metaphor break?
+5. **Extract insight**: What did we learn?
+
+## Example Collision
+
+**Problem:** Complex distributed system with cascading failures
+
+**Collision:** "What if we treated services like electrical circuits?"
+
+**Emergent properties:**
+- Circuit breakers (disconnect on overload)
+- Fuses (one-time failure protection)
+- Ground faults (error isolation)
+- Load balancing (current distribution)
+
+**Where it works:** Preventing cascade failures
+**Where it breaks:** Circuits don't have retry logic
+**Insight gained:** Failure isolation patterns from electrical engineering
+
+## Red Flags You Need This
+
+- "I've tried everything in this domain"
+- Solutions feel incremental, not breakthrough
+- Stuck in conventional thinking
+- Need innovation, not optimization
+
+## Remember
+
+- Wild combinations often yield best insights
+- Test metaphor boundaries rigorously
+- Document even failed collisions (they teach)
+- Best source domains: physics, biology, economics, psychology

skills/problem-solving/inversion-exercise/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: Inversion Exercise
+description: Flip core assumptions to reveal hidden constraints and alternative approaches - "what if the opposite were true?"
+when_to_use: Stuck on assumptions you can't question. Solution feels forced. "This is how it must be done" thinking. Want to challenge conventional wisdom. Need fresh perspective on problem.
+version: 1.0.0
+---
+
+# Inversion Exercise
+
+## Overview
+
+Flip every assumption and see what still works. Sometimes the opposite reveals the truth.
+
+**Core principle:** Inversion exposes hidden assumptions and alternative approaches.
+
+## Quick Reference
+
+| Normal Assumption | Inverted | What It Reveals |
+|-------------------|----------|-----------------|
+| Cache to reduce latency | Add latency to enable caching | Debouncing patterns |
+| Pull data when needed | Push data before needed | Prefetching, eager loading |
+| Handle errors when occur | Make errors impossible | Type systems, contracts |
+| Build features users want | Remove features users don't need | Simplicity >> addition |
+| Optimize for common case | Optimize for worst case | Resilience patterns |
+
+## Process
+
+1. **List core assumptions** - What "must" be true?
+2. **Invert each systematically** - "What if opposite were true?"
+3. **Explore implications** - What would we do differently?
+4. **Find valid inversions** - Which actually work somewhere?
+
+## Example
+
+**Problem:** Users complain app is slow
+
+**Normal approach:** Make everything faster (caching, optimization, CDN)
+
+**Inverted:** Make things intentionally slower in some places
+- Debounce search (add latency → enable better results)
+- Rate limit requests (add friction → prevent abuse)
+- Lazy load content (delay → reduce initial load)
+
+**Insight:** Strategic slowness can improve UX
+
+## Red Flags You Need This
+
+- "There's only one way to do this"
+- Forcing solution that feels wrong
+- Can't articulate why approach is necessary
+- "This is just how it's done"
+
+## Remember
+
+- Not all inversions work (test boundaries)
+- Valid inversions reveal context-dependence
+- Sometimes opposite is the answer
+- Question "must be" statements

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

skills/problem-solving/scale-game/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: Scale Game
+description: Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths hidden at normal scales
+when_to_use: Unsure if approach will scale. Edge cases unclear. Want to validate architecture. "Will this work at production scale?" Need to find fundamental limits.
+version: 1.0.0
+---
+
+# Scale Game
+
+## Overview
+
+Test your approach at extreme scales to find what breaks and what surprisingly survives.
+
+**Core principle:** Extremes expose fundamental truths hidden at normal scales.
+
+## Quick Reference
+
+| Scale Dimension | Test At Extremes | What It Reveals |
+|-----------------|------------------|-----------------|
+| Volume | 1 item vs 1B items | Algorithmic complexity limits |
+| Speed | Instant vs 1 year | Async requirements, caching needs |
+| Users | 1 user vs 1B users | Concurrency issues, resource limits |
+| Duration | Milliseconds vs years | Memory leaks, state growth |
+| Failure rate | Never fails vs always fails | Error handling adequacy |
+
+## Process
+
+1. **Pick dimension** - What could vary extremely?
+2. **Test minimum** - What if this was 1000x smaller/faster/fewer?
+3. **Test maximum** - What if this was 1000x bigger/slower/more?
+4. **Note what breaks** - Where do limits appear?
+5. **Note what survives** - What's fundamentally sound?
+
+## Examples
+
+### Example 1: Error Handling
+**Normal scale:** "Handle errors when they occur" works fine
+**At 1B scale:** Error volume overwhelms logging, crashes system
+**Reveals:** Need to make errors impossible (type systems) or expect them (chaos engineering)
+
+### Example 2: Synchronous APIs
+**Normal scale:** Direct function calls work
+**At global scale:** Network latency makes synchronous calls unusable
+**Reveals:** Async/messaging becomes survival requirement, not optimization
+
+### Example 3: In-Memory State
+**Normal duration:** Works for hours/days
+**At years:** Memory grows unbounded, eventual crash
+**Reveals:** Need persistence or periodic cleanup, can't rely on memory
+
+## Red Flags You Need This
+
+- "It works in dev" (but will it work in production?)
+- No idea where limits are
+- "Should scale fine" (without testing)
+- Surprised by production behavior
+
+## Remember
+
+- Extremes reveal fundamentals
+- What works at one scale fails at another
+- Test both directions (bigger AND smaller)
+- Use insights to validate architecture early

skills/problem-solving/simplification-cascades/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: Simplification Cascades
+description: Find one insight that eliminates multiple components - "if this is true, we don't need X, Y, or Z"
+when_to_use: Code has many similar-looking implementations. Growing list of special cases. Same concept handled 5 different ways. Excessive configuration. Many if/else branches doing similar things. Complexity spiraling.
+version: 1.0.0
+---
+
+# Simplification Cascades
+
+## Overview
+
+Sometimes one insight eliminates 10 things. Look for the unifying principle that makes multiple components unnecessary.
+
+**Core principle:** "Everything is a special case of..." collapses complexity dramatically.
+
+## Quick Reference
+
+| Symptom | Likely Cascade |
+|---------|----------------|
+| Same thing implemented 5+ ways | Abstract the common pattern |
+| Growing special case list | Find the general case |
+| Complex rules with exceptions | Find the rule that has no exceptions |
+| Excessive config options | Find defaults that work for 95% |
+
+## The Pattern
+
+**Look for:**
+- Multiple implementations of similar concepts
+- Special case handling everywhere
+- "We need to handle A, B, C, D differently..."
+- Complex rules with many exceptions
+
+**Ask:** "What if they're all the same thing underneath?"
+
+## Examples
+
+### Cascade 1: Stream Abstraction
+**Before:** Separate handlers for batch/real-time/file/network data
+**Insight:** "All inputs are streams - just different sources"
+**After:** One stream processor, multiple stream sources
+**Eliminated:** 4 separate implementations
+
+### Cascade 2: Resource Governance
+**Before:** Session tracking, rate limiting, file validation, connection pooling (all separate)
+**Insight:** "All are per-entity resource limits"
+**After:** One ResourceGovernor with 4 resource types
+**Eliminated:** 4 custom enforcement systems
+
+### Cascade 3: Immutability
+**Before:** Defensive copying, locking, cache invalidation, temporal coupling
+**Insight:** "Treat everything as immutable data + transformations"
+**After:** Functional programming patterns
+**Eliminated:** Entire classes of synchronization problems
+
+## Process
+
+1. **List the variations** - What's implemented multiple ways?
+2. **Find the essence** - What's the same underneath?
+3. **Extract abstraction** - What's the domain-independent pattern?
+4. **Test it** - Do all cases fit cleanly?
+5. **Measure cascade** - How many things become unnecessary?
+
+## Red Flags You're Missing a Cascade
+
+- "We just need to add one more case..." (repeating forever)
+- "These are all similar but different" (maybe they're the same?)
+- Refactoring feels like whack-a-mole (fix one, break another)
+- Growing configuration file
+- "Don't touch that, it's complicated" (complexity hiding pattern)
+
+## Remember
+
+- Simplification cascades = 10x wins, not 10% improvements
+- One powerful abstraction > ten clever hacks
+- The pattern is usually already there, just needs recognition
+- Measure in "how many things can we delete?"

skills/problem-solving/when-stuck/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: When Stuck - Problem-Solving Dispatch
+description: Dispatch to the right problem-solving technique based on how you're stuck
+when_to_use: Stuck on a problem. Conventional approaches not working. Need to pick the right problem-solving technique. Not sure which skill applies.
+version: 1.0.0
+---
+
+# When Stuck - Problem-Solving Dispatch
+
+## Overview
+
+Different stuck-types need different techniques. This skill helps you quickly identify which problem-solving skill to use.
+
+**Core principle:** Match stuck-symptom to technique.
+
+## Quick Dispatch
+
+```dot
+digraph stuck_dispatch {
+    rankdir=TB;
+    node [shape=box, style=rounded];
+
+    stuck [label="You're Stuck", shape=ellipse, style=filled, fillcolor=lightblue];
+
+    complexity [label="Same thing implemented 5+ ways?\nGrowing special cases?\nExcessive if/else?"];
+    innovation [label="Can't find fitting approach?\nConventional solutions inadequate?\nNeed breakthrough?"];
+    patterns [label="Same issue in different places?\nFeels familiar across domains?\nReinventing wheels?"];
+    assumptions [label="Solution feels forced?\n'This must be done this way'?\nStuck on assumptions?"];
+    scale [label="Will this work at production?\nEdge cases unclear?\nUnsure of limits?"];
+    bugs [label="Code behaving wrong?\nTest failing?\nUnexpected output?"];
+
+    stuck -> complexity;
+    stuck -> innovation;
+    stuck -> patterns;
+    stuck -> assumptions;
+    stuck -> scale;
+    stuck -> bugs;
+
+    complexity -> simp [label="yes"];
+    innovation -> collision [label="yes"];
+    patterns -> meta [label="yes"];
+    assumptions -> invert [label="yes"];
+    scale -> scale_skill [label="yes"];
+    bugs -> debug [label="yes"];
+
+    simp [label="skills/problem-solving/\nsimplification-cascades", shape=box, style="rounded,filled", fillcolor=lightgreen];
+    collision [label="skills/problem-solving/\ncollision-zone-thinking", shape=box, style="rounded,filled", fillcolor=lightgreen];
+    meta [label="skills/problem-solving/\nmeta-pattern-recognition", shape=box, style="rounded,filled", fillcolor=lightgreen];
+    invert [label="skills/problem-solving/\ninversion-exercise", shape=box, style="rounded,filled", fillcolor=lightgreen];
+    scale_skill [label="skills/problem-solving/\nscale-game", shape=box, style="rounded,filled", fillcolor=lightgreen];
+    debug [label="skills/debugging/\nsystematic-debugging", shape=box, style="rounded,filled", fillcolor=lightyellow];
+}
+```
+
+## Stuck-Type → Technique
+
+| How You're Stuck | Use This Skill |
+|------------------|----------------|
+| **Complexity spiraling** - Same thing 5+ ways, growing special cases | skills/problem-solving/simplification-cascades |
+| **Need innovation** - Conventional solutions inadequate, can't find fitting approach | skills/problem-solving/collision-zone-thinking |
+| **Recurring patterns** - Same issue different places, reinventing wheels | skills/problem-solving/meta-pattern-recognition |
+| **Forced by assumptions** - "Must be done this way", can't question premise | skills/problem-solving/inversion-exercise |
+| **Scale uncertainty** - Will it work in production? Edge cases unclear? | skills/problem-solving/scale-game |
+| **Code broken** - Wrong behavior, test failing, unexpected output | skills/debugging/systematic-debugging |
+| **Multiple independent problems** - Can parallelize investigation | skills/collaboration/dispatching-parallel-agents |
+| **Root cause unknown** - Symptom clear, cause hidden | skills/debugging/root-cause-tracing |
+
+## Process
+
+1. **Identify stuck-type** - What symptom matches above?
+2. **Load that skill** - Read the specific technique
+3. **Apply technique** - Follow its process
+4. **If still stuck** - Try different technique or combine
+
+## Combining Techniques
+
+Some problems need multiple techniques:
+
+- **Simplification + Meta-pattern**: Find pattern, then simplify all instances
+- **Collision + Inversion**: Force metaphor, then invert its assumptions
+- **Scale + Simplification**: Extremes reveal what to eliminate
+
+## Remember
+
+- Match symptom to technique
+- One technique at a time
+- Combine if first doesn't work
+- Document what you tried