Complex Reasoning Skill

Structured reasoning frameworks for systematic problem solving, leveraging extended thinking capabilities for deep analysis.

When to Use Debugging complex issues with multiple potential causes Architecture decisions requiring trade-off analysis Root cause analysis for production incidents Performance optimization with multiple variables Security vulnerability assessment Code refactoring with many dependencies Reasoning Frameworks Chain-of-Thought (CoT)

Linear step-by-step reasoning for sequential problems.

Chain-of-Thought Analysis

Problem: [State the problem clearly]

Step 1: Understand the Context - What do we know? - What are the constraints? - What is the expected outcome?

Step 2: Identify Key Components - Component A: [description] - Component B: [description] - Interactions: [how they relate]

Step 3: Analyze Each Component - Component A analysis... - Component B analysis...

Step 4: Synthesize Findings - Key insight 1 - Key insight 2

Step 5: Formulate Solution - Recommended approach - Rationale - Trade-offs

Conclusion: [Final recommendation with confidence level]

Tree-of-Thought (ToT)

Branching exploration for problems with multiple solution paths.

Tree-of-Thought Exploration

Root Problem: [Problem statement]

Branch 1: Approach A

├── Pros: [List advantages] ├── Cons: [List disadvantages] ├── Feasibility: [High/Medium/Low] ├── Sub-branch 1.1: [Variation] │ └── Outcome: [Expected result] └── Sub-branch 1.2: [Variation] └── Outcome: [Expected result]

Branch 2: Approach B

├── Pros: [List advantages] ├── Cons: [List disadvantages] ├── Feasibility: [High/Medium/Low] └── Sub-branches: [...]

Branch 3: Approach C

├── Pros: [...] ├── Cons: [...] └── Feasibility: [...]

Evaluation Matrix

| Approach | Feasibility | Impact | Risk | Score |

|----------|-------------|--------|------|-------|

| A | High | Medium | Low | 8/10 |

| B | Medium | High | Med | 7/10 |

| C | Low | High | High | 5/10 |

Selected Path: Branch [X] because [reasoning]

MECE Framework

Mutually Exclusive, Collectively Exhaustive analysis.

MECE Analysis

Problem Space: [Define the complete problem]

Category 1: [Mutually exclusive category]

• Sub-element 1.1
• Sub-element 1.2
• Sub-element 1.3

Category 2: [Mutually exclusive category]

• Sub-element 2.1
• Sub-element 2.2

Category 3: [Mutually exclusive category]

• Sub-element 3.1
• Sub-element 3.2
• Sub-element 3.3

Completeness Check: - [ ] Categories are mutually exclusive (no overlap) - [ ] Categories are collectively exhaustive (cover all cases) - [ ] Each sub-element belongs to exactly one category

Priority Matrix:

| Category | Urgency | Impact | Action |

|----------|---------|--------|--------|

| 1 | High | High | Now |

| 2 | Medium | High | Next |

| 3 | Low | Medium | Later |

Hypothesis-Driven Debugging

Systematic approach to debugging complex issues.

Hypothesis-Driven Debug Session

Symptom: [Observed behavior] Expected: [What should happen] Environment: [Relevant context]

Hypothesis 1: [Most likely cause]

Evidence For: - [Supporting observation 1] - [Supporting observation 2]

Evidence Against: - [Contradicting observation]

Test: [How to validate] Result: [Confirmed/Refuted]

Hypothesis 2: [Second most likely]

Evidence For: - [...]

Evidence Against: - [...]

Test: [...] Result: [...]

Root Cause Identified

Cause: [Confirmed root cause] Evidence Chain: [How we proved it] Fix: [Remediation steps] Prevention: [How to prevent recurrence]

Code Analysis Patterns Dependency Analysis

Dependency Analysis: [Component Name]

Direct Dependencies

| Dependency | Version | Purpose | Risk Level |

|------------|---------|---------|------------|

| dep-a | 2.3.1 | Auth | Low |

| dep-b | 1.0.0 | Data | Medium |

Transitive Dependencies

• Total: [N] packages
• Security vulnerabilities: [N]
• Outdated: [N]

Dependency Graph

[component] ├── dep-a │ ├── sub-dep-1 │ └── sub-dep-2 └── dep-b └── sub-dep-3

Risk Assessment

1. High Risk: [Dependencies with known issues]
2. Medium Risk: [Outdated or unmaintained]
3. Low Risk: [Stable, well-maintained]

Recommendations

1. [Action item 1]
2. [Action item 2]

Impact Analysis

Impact Analysis: [Proposed Change]

Affected Components

| Component | Impact Type | Severity | Test Required |

|-----------|-------------|----------|---------------|

| Service A | Direct | High | Yes |

| Service B | Indirect | Medium | Yes |

| Client C | Downstream | Low | Optional |

Risk Assessment

• Breaking Changes: [List any]
• Performance Impact: [Expected effect]
• Data Migration: [Required/Not required]

Rollback Plan

1. [Step 1]
2. [Step 2]
3. [Verification]

Recommendation

[Go/No-Go with reasoning]

Integration with Extended Thinking

When using these frameworks with extended thinking:

Enable extended thinking for complex reasoning

response = client.messages.create( model="claude-opus-4-5-20250514", max_tokens=16000, thinking={ "type": "enabled", "budget_tokens": 15000 # Higher budget for complex reasoning }, system="""You are a systematic problem solver. Use structured reasoning frameworks like Chain-of-Thought, Tree-of-Thought, or MECE analysis as appropriate for the problem.""", messages=[{ "role": "user", "content": "Analyze this architecture decision using ToT..." }] )

Best Practices Choose the right framework: CoT for linear problems, ToT for branching decisions Document your reasoning: Makes it reviewable and repeatable Validate assumptions: Each step should build on verified facts Consider alternatives: Always explore at least 2-3 approaches Quantify when possible: Use metrics to compare options Time-box exploration: Set limits on analysis depth See Also [[extended-thinking]] - Enable deep reasoning capabilities [[deep-analysis]] - Analytical templates [[debugging]] - General debugging patterns [[testing]] - Validation strategies