Problem Solving Techniques

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

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

Problem-Solving Skills - Attribution

These skills were derived from agent patterns in the Amplifier project.

Source Repository:

• Name: Amplifier
• URL: https://github.com/microsoft/amplifier
• Commit: 2adb63f858e7d760e188197c8e8d4c1ef721e2a6
• Date: 2025-10-10

Skills Derived from Amplifier Agents

From insight-synthesizer agent:

• simplification-cascades - Finding insights that eliminate multiple components
• collision-zone-thinking - Forcing unrelated concepts together for breakthroughs
• meta-pattern-recognition - Spotting patterns across 3+ domains
• inversion-exercise - Flipping assumptions to reveal alternatives
• scale-game - Testing at extremes to expose fundamental truths

From ambiguity-guardian agent:

• (architecture) preserving-productive-tensions - Preserving multiple valid approaches

From knowledge-archaeologist agent:

• (research) tracing-knowledge-lineages - Understanding how ideas evolved

Dispatch pattern:

• when-stuck - Maps stuck-symptoms to appropriate technique

What Was Adapted

The amplifier agents are specialized long-lived agents with structured JSON output. These skills extract the core problem-solving techniques and adapt them as:

• Scannable quick-reference guides (~60 lines each)
• Symptom-based discovery via when_to_use
• Immediate application without special tooling
• Composable through dispatch pattern

Core Insight

Agent capabilities are domain-agnostic patterns. Whether packaged as "amplifier agent" or "superpowers skill", the underlying technique is the same. We extracted the techniques and made them portable.

Problem-Solving Skills - Attribution

These skills were derived from agent patterns in the Microsoft Amplifier project.

Source Repository

• Name: Amplifier
• URL: https://github.com/microsoft/amplifier
• Commit: 2adb63f858e7d760e188197c8e8d4c1ef721e2a6
• Date: 2025-10-10

Skills Derived from Amplifier Agents

From insight-synthesizer agent:

• simplification-cascades - Finding insights that eliminate multiple components
• collision-zone-thinking - Forcing unrelated concepts together for breakthroughs
• meta-pattern-recognition - Spotting patterns across 3+ domains
• inversion-exercise - Flipping assumptions to reveal alternatives
• scale-game - Testing at extremes to expose fundamental truths

From ambiguity-guardian agent:

• preserving-productive-tensions - Preserving multiple valid approaches (in architecture skill)

From knowledge-archaeologist agent:

• tracing-knowledge-lineages - Understanding how ideas evolved (in research skill)

Dispatch pattern:

• when-stuck - Maps stuck-symptoms to appropriate technique

What Was Adapted

The Amplifier agents are specialized long-lived agents with structured JSON output. These skills extract the core problem-solving techniques and adapt them as:

• Scannable quick-reference guides (~60-80 lines each)
• Symptom-based discovery via when_to_use descriptions
• Immediate application without special tooling
• Composable patterns through dispatch system
• Progressive disclosure via SKILL.md + references structure

Core Insight

Agent capabilities are domain-agnostic patterns. Whether packaged as "amplifier agent" or "problem-solving skill", the underlying technique is the same.

We extracted the techniques and made them:

• Portable across contexts
• Immediately applicable
• Token-efficient through progressive disclosure
• Discoverable through symptom-matching
• Combinable for complex problems

License

Original Amplifier project uses MIT License. These adapted skills maintain attribution and follow the same open spirit.

Adaptation Notes

Changes from original:

• Converted from long-lived agent to scannable reference
• Added symptom-based dispatch system
• Removed JSON output requirements
• Focused on immediate application
• Added concrete examples
• Structured for progressive disclosure

Preserved from original:

• Core problem-solving techniques
• Recognition patterns
• Application processes
• Fundamental insights

Collision-Zone Thinking

Force unrelated concepts together to discover emergent properties. "What if we treated X like Y?"

Core Principle

Revolutionary insights from deliberate metaphor-mixing. Treat X like Y and see what emerges.

When to Use

Quick Reference Collisions

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?

Detailed Example

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)
• Voltage regulation (rate limiting)

Where it works: Preventing cascade failures, fault isolation

Where it breaks: Circuits don't have retry logic, healing mechanisms

Insight gained: Failure isolation patterns from electrical engineering

Best Source Domains

Rich domains for concept mining:

• Physics - Forces, thermodynamics, relativity
• Biology - Evolution, ecosystems, immune systems
• Economics - Markets, incentives, game theory
• Psychology - Cognition, behavior, motivation
• Architecture - Structure, flow, space utilization

Red Flags

You need collision-zone thinking when:

• "I've tried everything in this domain"
• Solutions feel incremental, not breakthrough
• Stuck in conventional thinking
• Need innovation, not optimization
• "Standard approach isn't working"

Remember

• Wild combinations often yield best insights
• Test metaphor boundaries rigorously
• Document even failed collisions (they teach)
• Breakthrough > incremental improvement
• Question: "What would [domain expert] do?"

Inversion Exercise

Flip core assumptions to reveal hidden constraints and alternative approaches. "What if the opposite were true?"

Core Principle

Inversion exposes hidden assumptions. Sometimes the opposite reveals the truth.

When to Use

Quick Reference

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? 5. Document insights - What did we learn?

Detailed Example

Problem: Users complain app is slow

Normal approach: Make everything faster

• Add caching
• Optimize queries
• Use CDN
• Reduce bundle size

Inverted approach: Make things intentionally slower in some places

• Debounce search - Add latency → enable better results (wait for full query)
• Rate limit requests - Add friction → prevent abuse, improve for others
• Lazy load content - Delay loading → reduce initial load time
• Progressive rendering - Show slower → perceived performance

Insight: Strategic slowness can improve UX

Valid vs Invalid Inversions

Valid inversion example:

• Normal: "Store data in database"
• Inverted: "Derive data on-demand instead of storing"
• Valid when: Computation cheaper than storage, data changes frequently

Invalid inversion example:

• Normal: "Validate user input"
• Inverted: "Trust all user input"
• Invalid because: Security vulnerability, not context-dependent

Test validity: Does the inversion work in ANY context? If yes, it's valid somewhere.

Common Inversions

• Eager → Lazy (or vice versa)
• Push → Pull (or vice versa)
• Store → Compute (or vice versa)
• Optimize → Simplify (or vice versa)
• Add features → Remove features (or vice versa)

Red Flags

You need inversion exercise when:

• "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"
• Stuck on unquestioned assumptions

Remember

• Not all inversions work (test boundaries)
• Valid inversions reveal context-dependence
• Sometimes opposite is the answer
• Question "must be" statements
• Document both successful and failed inversions

Meta-Pattern Recognition

Spot patterns appearing in 3+ domains to find universal principles.

Core Principle

Find patterns in how patterns emerge. When the same pattern appears in 3+ domains, it's likely a universal principle worth extracting.

When to Use

Quick Reference

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? 5. Document pattern - Make it reusable

Detailed Example

Pattern spotted: Rate limiting appears in:

• API throttling (requests per minute)
• Traffic shaping (packets per second)
• Circuit breakers (failures per window)
• Admission control (concurrent connections)

Abstract form: Bound resource consumption to prevent exhaustion

Variation points:

• What resource (requests, packets, failures, connections)
• What limit (per time window, concurrent, cumulative)
• What happens when exceeded (reject, queue, degrade)

New application: LLM token budgets

• Same pattern: prevent context window exhaustion
• Resource: tokens
• Limit: context window size
• Action: truncate or reject

3+ Domain Rule

Why 3 domains?

• 1 occurrence = coincidence
• 2 occurrences = possible pattern
• 3+ occurrences = likely universal

Domain independence test: Can you describe the pattern without mentioning specific domains?

Red Flags

Signs you're missing meta-patterns:

• "This problem is unique" (probably not)
• Multiple teams solving "different" problems identically
• Reinventing wheels across domains
• "Haven't we done something like this?" (yes, find it)

Benefits of Meta-Patterns

• Battle-tested - Proven across multiple domains
• Reusable - Apply to new situations
• Universal - Domain-independent solutions
• Documented - Known variations and trade-offs

Remember

• 3+ domains = likely universal
• Abstract form reveals new applications
• Variations show adaptation points
• Universal patterns save time
• Document for future reuse

Scale Game

Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths hidden at normal scales.

Core Principle

Extremes expose fundamentals. What works at one scale fails at another.

When to Use

Quick Reference

Process

1. Pick dimension - What could vary extremely? 2. Test minimum - What if 1000x smaller/faster/fewer? 3. Test maximum - What if 1000x bigger/slower/more? 4. Note what breaks - Where do limits appear? 5. Note what survives - What's fundamentally sound? 6. Design for reality - Use insights to validate architecture

Detailed 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)
• Action: Design error handling for volume, not just occurrence

Example 2: Synchronous APIs

• Normal scale: Direct function calls work, < 100ms latency
• At global scale: Network latency makes synchronous unusable (200-500ms)
• Reveals: Async/messaging becomes survival requirement, not optimization
• Action: Design async-first from start

Example 3: In-Memory State

• Normal duration: Works for hours/days in development
• At years: Memory grows unbounded, eventual crash (weeks → months → years)
• Reveals: Need persistence or periodic cleanup, can't rely on memory forever
• Action: Design for stateless or externalized state

Example 4: Single vs Million Users

• Normal scale: Session in memory works for 100 users
• At 1M scale: Memory exhausted, server crashes
• Reveals: Need distributed session store (Redis, database)
• Action: Design for horizontal scaling from start

Both Directions Matter

Test smaller too:

• What if only 1 user? Does complexity make sense?
• What if only 10 items? Is optimization premature?
• What if instant response? What becomes unnecessary?

Often reveals over-engineering or premature optimization.

Red Flags

You need scale game when:

• "It works in dev" (but will it work in production?)
• No idea where limits are
• "Should scale fine" (without evidence)
• Surprised by production behavior
• Architecture feels arbitrary

Success Metrics

After scale game, you should know:

• Where system breaks (exact limits)
• What survives (fundamentally sound parts)
• What needs redesign (scale-dependent)
• Production readiness (validated architecture)

Remember

• Extremes reveal fundamentals hidden at normal scales
• What works at one scale fails at another
• Test BOTH directions (bigger AND smaller)
• Use insights to validate architecture early
• Don't guess - test at extremes

Simplification Cascades

Find one insight eliminating multiple components. "If this is true, we don't need X, Y, Z."

Core Principle

Everything is a special case of... collapses complexity dramatically.

One powerful abstraction > ten clever hacks.

When to Use

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

Example 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

Example 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

Example 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 variations - What's implemented multiple ways? 2. Find essence - What's the same underneath? 3. Extract abstraction - What's the domain-independent pattern? 4. Test fit - Do all cases fit cleanly? 5. Measure cascade - How many things become unnecessary?

Red Flags

Signs you're missing a cascade:

• "Just need to add one more case..." (repeating forever)
• "These are 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)

Success Metrics

• 10x wins, not 10% improvements
• Measure in "how many things can we delete?"
• Lines of code removed > lines added
• Configuration options eliminated
• Special cases unified

Remember

• The pattern is usually already there, just needs recognition
• Valid cascades feel obvious in retrospect
• Test with "can this handle all existing cases?"
• Document the insight for future reference

When Stuck - Problem-Solving Dispatch

Different stuck-types need different techniques. Match stuck-symptom to technique.

Dispatch Flowchart

YOU'RE STUCK
│
├─ Complexity spiraling? Same thing 5+ ways? Growing special cases?
│  └─→ USE: Simplification Cascades
│
├─ Can't find fitting approach? Conventional solutions inadequate?
│  └─→ USE: Collision-Zone Thinking
│
├─ Same issue different places? Reinventing wheels? Feels familiar?
│  └─→ USE: Meta-Pattern Recognition
│
├─ Solution feels forced? "Must be done this way"? Stuck on assumptions?
│  └─→ USE: Inversion Exercise
│
├─ Will this work at production? Edge cases unclear? Unsure of limits?
│  └─→ USE: Scale Game
│
└─ Code broken? Wrong behavior? Test failing?
   └─→ USE: Debugging skill (systematic-debugging)

Stuck-Type → Technique Map

Process

1. Identify stuck-type - What symptom matches above? 2. Load that technique - Read the specific reference file 3. Apply technique - Follow its process 4. Document attempt - What worked/failed? 5. If still stuck - Try different technique or combine

Combining Techniques

Some problems need multiple techniques:

• Simplification + Meta-pattern - Find pattern → simplify all instances
• Collision + Inversion - Force metaphor → invert assumptions
• Scale + Simplification - Test extremes → reveal what to eliminate
• Meta-pattern + Scale - Universal pattern → test at extremes

When Nothing Works

If no technique helps: 1. Reframe problem - Are you solving the right problem? 2. Get fresh perspective - Explain to someone else 3. Take break - Distance often reveals solution 4. Simplify scope - Solve smaller version first 5. Question constraints - Are they real or assumed?

Remember

• Match symptom to technique
• One technique at a time
• Combine if first doesn't work
• Document what you tried
• Not stuck forever, just temporarily