Problem Solving

This skill guides systematic approaches to debugging, solution design, and code comprehension. Apply these methodologies when facing technical challenges, exploring unfamiliar codebases, or making architectural decisions.

The user provides a problem to solve: a bug to fix, a feature to design, code to understand, or a technical decision to make. They may include error messages, code snippets, or context about the system.

Problem-Solving Thinking

Before diving into solutions, understand the problem deeply:

• •Symptom vs. Root Cause: What is the visible issue? What is the underlying cause?
• •Scope: Is this a local issue or a systemic problem?
• •Constraints: What are the technical, time, and resource constraints?
• •Success Criteria: How will you know the problem is solved?

CRITICAL: Never treat symptoms. Always find and fix the root cause. A quick fix that masks the issue will resurface later with greater impact.

When This Applies

Use this skill when:

• •Debugging errors or unexpected behavior
• •Designing solutions for new features
• •Understanding unfamiliar codebases
• •Making technical decisions with trade-offs
• •Investigating performance issues
• •Analyzing system failures

Tree of Thoughts Problem-Solving

Applies to: Complex problems with multiple potential solutions, architectural decisions, debugging

Methodology

Explore problems like a tree, branching into multiple potential solutions before committing:

Problem
├── Solution A
│   ├── Pro: Fast implementation
│   ├── Con: Technical debt
│   └── Risk: May not scale
├── Solution B
│   ├── Pro: Clean architecture
│   ├── Con: More time needed
│   └── Risk: Over-engineering
└── Solution C
    ├── Pro: Reuses existing code
    ├── Con: Couples to legacy system
    └── Risk: Maintenance burden

Steps

1. •Define the problem clearly - What exactly needs to be solved?
2. •Generate multiple solutions - At least 2-3 different approaches
3. •Evaluate each branch - Consider trade-offs for each
4. •Select and justify - Choose based on constraints and priorities
5. •Validate the choice - Ensure it addresses root cause

Evaluation Criteria

Graph of Thoughts Code Comprehension

Applies to: Understanding unfamiliar codebases, system analysis, onboarding

Methodology

Map code relationships as a graph to understand how components interact:

[Controller] ──calls──> [Service] ──uses──> [Repository]
      │                     │                     │
      │                     v                     v
      │              [Domain Model] <──maps── [Entity]
      │                     │
      └──────returns───────>│

Analysis Approaches

Top-Down Analysis:

1. •Start with entry points (main, routes, handlers)
2. •Follow the request/data flow downward
3. •Identify major components and their responsibilities
4. •Drill into details only as needed

Bottom-Up Analysis:

1. •Start with data models and entities
2. •Find what uses them
3. •Build up understanding of data flow
4. •Connect to entry points

Combine Both: Use top-down for architecture overview, bottom-up for specific feature understanding.

What to Map

Root Cause Analysis

Applies to: Debugging, incident response, preventing recurrence

The 5 Whys Technique

Keep asking "why" until you reach the root cause (typically 5 levels):

Problem: Production server crashed
Why 1: Memory exhausted
Why 2: Memory leak in image processing
Why 3: Images not released after processing
Why 4: Exception skipped cleanup code
Why 5: No try-finally around resource allocation
Root Cause: Missing resource cleanup pattern

Debugging Methodology

Common Root Cause Categories

Decision Framework

Applies to: Technical decisions, architecture choices, tool selection

Decision Documentation

For significant decisions, document:

## Decision: [Title]

### Context
What is the situation? What problem are we solving?

### Options Considered
1. Option A: [Description]
   - Pros: ...
   - Cons: ...

2. Option B: [Description]
   - Pros: ...
   - Cons: ...

### Decision
We chose Option [X] because...

### Consequences
- Positive: ...
- Negative: ...
- Risks: ...

Trade-off Analysis

Performance Investigation

Applies to: Slow operations, resource issues, scalability problems

Investigation Steps

1. •Measure - Profile before optimizing (don't guess)
2. •Identify - Find the actual bottleneck
3. •Analyze - Understand why it's slow
4. •Optimize - Fix the specific bottleneck
5. •Verify - Measure improvement

Common Performance Issues

Platform-Specific Debugging

Mobile (iOS/Android/Flutter)

Applies to: Mobile application issues

Web (Frontend)

Applies to: Web application issues

Backend (APIs/Services)

Applies to: Server-side issues

Anti-Patterns (NEVER use)

• •Shotgun debugging: Making random changes hoping something works
• •Symptom fixing: Addressing visible issues without finding root cause
• •Single-solution thinking: Not considering alternatives
• •Premature optimization: Optimizing without profiling first
• •Blame-first debugging: Assuming the problem is elsewhere
• •Ignoring context: Not understanding the system before changing it
• •Copy-paste fixing: Applying fixes without understanding them

Core Philosophy

"Given enough eyeballs, all bugs are shallow." — Linus's Law

Approach every problem systematically. Understand before you act. Fix root causes, not symptoms. Document decisions for future reference.