| name | ultra-think |
| description | Master advanced cognitive and analytical thinking patterns for deep problem solving, including first principles reasoning, mental models, systematic decomposition, and critical evaluation. Use PROACTIVELY for complex problems, architectural decisions, debugging, or strategic planning. |
Ultra Think
Master advanced cognitive and analytical thinking patterns for deep problem solving, systematic analysis, and strategic decision making.
When to Use This Skill
- Solving complex, multi-faceted problems
- Making architectural or design decisions
- Debugging difficult issues with unknown root causes
- Analyzing trade-offs between alternatives
- Planning strategies and roadmaps
- Evaluating proposals and designs
- Breaking down ambiguous requirements
- Synthesizing information from multiple sources
Core Thinking Frameworks
1. First Principles Thinking
Break problems down to fundamental truths and reason up from there.
FIRST PRINCIPLES PROCESS:
1. IDENTIFY THE PROBLEM
└── What exactly are we trying to solve?
└── What assumptions are we making?
└── What do we "know" that might not be true?
2. BREAK DOWN TO FUNDAMENTALS
└── What are the basic elements?
└── What physical/logical laws apply?
└── What are the irreducible requirements?
3. REMOVE ASSUMPTIONS
└── Why do we do it this way?
└── Is this constraint real or inherited?
└── What if we started from scratch?
4. REBUILD FROM GROUND UP
└── Given fundamentals, what's the optimal solution?
└── What new approaches become possible?
└── What would an expert with no context do?
Example Application:
PROBLEM: Database queries are slow
CONVENTIONAL THINKING:
- Add more indexes
- Upgrade to larger instance
- Add caching layer
FIRST PRINCIPLES:
1. Fundamentals:
- Data must be read from storage
- Query must match records
- Results must be returned
2. Remove assumptions:
- Do we need relational structure?
- Do we need real-time consistency?
- Is the data model correct for access patterns?
3. Rebuild:
- Maybe: denormalize for read patterns
- Maybe: use event sourcing + projections
- Maybe: pre-compute and store results
- Maybe: different database type entirely
2. Mental Models Library
Apply proven thinking frameworks to structure analysis.
┌─────────────────────────────────────────────────────────────────────┐
│ MENTAL MODEL TOOLKIT │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ SYSTEMS THINKING │
│ ├── Feedback Loops: What reinforces or dampens behavior? │
│ ├── Emergent Properties: What arises from component interaction? │
│ ├── Bottlenecks: Where does the system constrain flow? │
│ └── Leverage Points: Where can small changes have big impact? │
│ │
│ INVERSION │
│ ├── Instead of: How do I succeed? │
│ ├── Ask: How would I definitely fail? │
│ └── Then: Avoid those failure modes │
│ │
│ SECOND-ORDER EFFECTS │
│ ├── First-order: What happens immediately? │
│ ├── Second-order: What happens as a result of that? │
│ └── Third-order: And then what happens? │
│ │
│ OPPORTUNITY COST │
│ ├── What am I giving up by choosing this? │
│ ├── What else could I do with these resources? │
│ └── Is this the highest-value use of time/effort? │
│ │
│ PARETO PRINCIPLE (80/20) │
│ ├── Which 20% of causes create 80% of effects? │
│ ├── Which 20% of effort produces 80% of results? │
│ └── Focus on the vital few, not the trivial many │
│ │
│ OCCAM'S RAZOR │
│ ├── Among competing hypotheses, prefer the simplest │
│ ├── Don't add complexity without evidence │
│ └── Simple explanations are more likely correct │
│ │
│ HANLON'S RAZOR │
│ ├── Don't attribute to malice what is explained by incompetence │
│ ├── Most failures are mistakes, not intentional │
│ └── Assume good intent until proven otherwise │
│ │
└─────────────────────────────────────────────────────────────────────┘
3. Problem Decomposition
Systematically break complex problems into manageable pieces.
DECOMPOSITION STRATEGY:
┌──────────────────────────────────────────────────────────────┐
│ ORIGINAL PROBLEM │
│ "System is unreliable and users complain" │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ CLARIFY & BOUND │
│ • What does "unreliable" mean specifically? │
│ • Which users? What do they complain about? │
│ • What's the scope? (time, components, severity) │
│ • What's the success criteria? │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ IDENTIFY DIMENSIONS │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ SYMPTOMS │ │ CAUSES │ │ IMPACTS │ │
│ ├─────────────┤ ├─────────────┤ ├─────────────┤ │
│ │ • Errors │ │ • Code bugs │ │ • Lost data │ │
│ │ • Timeouts │ │ • Infra │ │ • Downtime │ │
│ │ • Slow │ │ • Load │ │ • Revenue │ │
│ │ • Data loss │ │ • External │ │ • Trust │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└──────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ PRIORITIZE & SEQUENCE │
│ │
│ 1. [HIGH] Data loss in checkout → Fix transaction handling │
│ 2. [HIGH] API timeouts during peak → Add circuit breakers │
│ 3. [MED] Intermittent errors → Improve observability │
│ 4. [LOW] Slow dashboard → Optimize queries later │
└──────────────────────────────────────────────────────────────┘
4. Trade-off Analysis
Structure decision-making when facing competing options.
TRADE-OFF ANALYSIS FRAMEWORK:
OPTION A: Microservices Architecture
OPTION B: Modular Monolith
OPTION C: Hybrid (Critical services split, rest monolith)
┌─────────────────────────┬─────────┬─────────┬─────────┐
│ CRITERIA (weighted) │ Opt A │ Opt B │ Opt C │
├─────────────────────────┼─────────┼─────────┼─────────┤
│ Development speed (3x) │ 2 │ 4 │ 3 │
│ Scalability (2x) │ 5 │ 2 │ 4 │
│ Operational complexity │ 1 │ 4 │ 3 │
│ Team expertise (2x) │ 2 │ 4 │ 3 │
│ Future flexibility │ 5 │ 3 │ 4 │
│ Time to market (3x) │ 1 │ 5 │ 4 │
├─────────────────────────┼─────────┼─────────┼─────────┤
│ WEIGHTED SCORE │ 27 │ 41 │ 38 │
└─────────────────────────┴─────────┴─────────┴─────────┘
DECISION FACTORS:
├── Reversibility: Can we change our mind? (B → A easier than A → B)
├── Timing: When do we need scalability? (Not immediately)
├── Team: What can we execute well? (B most familiar)
└── Risk: What's the cost of being wrong? (A locks us in)
RECOMMENDATION: Option B (Modular Monolith)
├── Start simple, prove the product
├── Design for extractability (clear module boundaries)
├── Revisit when hitting concrete scaling limits
└── Lower operational burden with current team
5. Root Cause Analysis
Dig deep to find the true source of problems.
5 WHYS ANALYSIS:
SYMPTOM: Production deployment failed
WHY 1: Deployment script exited with error
└── Because database migration failed
WHY 2: Why did migration fail?
└── Because it tried to add NOT NULL column
WHY 3: Why was that a problem?
└── Because existing rows had NULL values
WHY 4: Why were there NULL values?
└── Because feature was deployed before data cleanup
WHY 5: Why was deployment before cleanup?
└── Because there's no coordination between data and code deploys
ROOT CAUSE: No deployment checklist ensuring data readiness
SOLUTIONS:
├── Immediate: Run data cleanup, re-deploy
├── Short-term: Create deployment checklist
└── Long-term: Automate pre-deployment validations
────────────────────────────────────────────────────────────────
FISHBONE DIAGRAM (ISHIKAWA):
┌─ Process ─────────────────┐
│ └─ No review process │
│ └─ Missing checklist │
│ │
┌─ People ──────│ ┌─ Technology ─────│
│ └─ Rushed │ │ └─ No validation│
│ └─ No training│ │ └─ Poor tooling │
│ │ │ │
│ ▼ │ │
└────────────→ [DEPLOYMENT FAILURE] ←───────┘
▲ ▲
┌───────────────│ │───────────────────┐
│ │ │ │
│ ┌─ Environment └─ Materials ──────│
│ │ └─ Prod/Dev drift │ └─ Bad data │
│ │ └─ Config mismatch │ └─ Missing docs │
└──┴─────────────────────┴──────────────────┘
6. Hypothesis-Driven Investigation
Use scientific method for debugging and analysis.
HYPOTHESIS-DRIVEN DEBUGGING:
1. OBSERVE
└── Symptoms: 500 errors spike at 9 AM daily
└── Context: Coincides with batch job start
└── Metrics: Memory usage climbs before errors
2. FORM HYPOTHESES (ranked by likelihood)
H1: Memory leak during batch processing
H2: Database connection exhaustion
H3: External API rate limiting
3. TEST EACH HYPOTHESIS
H1 TEST: [CONFIRMED]
├── Action: Profile memory during batch job
├── Prediction: Memory continuously increases
└── Result: Found list accumulation in loop
H2 TEST: [Not needed - H1 confirmed]
H3 TEST: [Not needed - H1 confirmed]
4. VALIDATE FIX
├── Action: Stream processing instead of collect
├── Prediction: Memory stays flat
└── Result: Memory stable, no more 500s
5. PREVENT RECURRENCE
├── Add memory limit alerts
├── Add to code review checklist
└── Document pattern in wiki
7. Strategic Thinking Patterns
Think beyond immediate problems to long-term impact.
STRATEGIC ANALYSIS LAYERS:
┌────────────────────────────────────────────────────────────┐
│ LAYER 1: IMMEDIATE TACTICAL │
│ "What do we do right now?" │
│ • Fix the bug │
│ • Patch the security hole │
│ • Handle the customer complaint │
└────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────┐
│ LAYER 2: OPERATIONAL │
│ "How do we prevent this class of problem?" │
│ • Improve testing coverage │
│ • Add security scanning to CI │
│ • Create feedback collection process │
└────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────┐
│ LAYER 3: STRATEGIC │
│ "How does this fit our long-term direction?" │
│ • Is our architecture supporting or hindering? │
│ • Do we have the right team capabilities? │
│ • Are we solving the right problems? │
└────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────┐
│ LAYER 4: VISION │
│ "Where are we trying to go?" │
│ • What does success look like in 3 years? │
│ • What must be true for that to happen? │
│ • What are we NOT going to do? │
└────────────────────────────────────────────────────────────┘
8. Synthesis and Integration
Combine insights from multiple sources into coherent understanding.
SYNTHESIS FRAMEWORK:
INPUTS:
├── Data Source 1: Performance metrics
├── Data Source 2: User feedback
├── Data Source 3: Team observations
├── Data Source 4: Market research
└── Data Source 5: Competitor analysis
PROCESS:
┌──────────────────────────────────────────────────────────┐
│ 1. EXTRACT KEY INSIGHTS │
│ ├── Performance: P95 latency up 200% in 6 months │
│ ├── Users: "App feels sluggish" top complaint │
│ ├── Team: Frontend bundle grew 3x with new features │
│ ├── Market: Mobile-first competitors gaining share │
│ └── Competition: They load 2x faster on mobile │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ 2. FIND PATTERNS & CONNECTIONS │
│ ├── Bundle growth → slower loads → user complaints │
│ ├── Mobile gap → competitive disadvantage │
│ └── Performance debt accumulated with feature growth │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ 3. FORM INTEGRATED UNDERSTANDING │
│ │
│ "We've traded performance for feature velocity, │
│ creating a mobile experience gap that competitors │
│ are exploiting. This threatens user retention and │
│ market position." │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ 4. DERIVE ACTIONABLE CONCLUSIONS │
│ ├── Immediate: Performance budget for new features │
│ ├── Short-term: Mobile performance sprint │
│ ├── Medium-term: Architecture review │
│ └── Long-term: Performance as product north star │
└──────────────────────────────────────────────────────────┘
Application Checklist
Before Starting Analysis
During Analysis
After Analysis
Quick Reference: Thinking Triggers
| Situation | Framework to Apply |
|---|
| "We've always done it this way" | First Principles |
| "What could go wrong?" | Inversion, Pre-mortem |
| "It's complicated" | Decomposition |
| "Which option should we choose?" | Trade-off Analysis |
| "Why did this happen?" | 5 Whys, Fishbone |
| "What's really going on?" | Root Cause Analysis |
| "What should we do about X?" | Strategic Layers |
| "How does this all fit together?" | Synthesis |
Common Thinking Traps
| Trap | Description | Antidote |
|---|
| Confirmation Bias | Seeking evidence that supports existing beliefs | Actively seek disconfirming evidence |
| Anchoring | Over-relying on first piece of information | Consider multiple starting points |
| Sunk Cost | Continuing because of past investment | Focus only on future costs/benefits |
| Availability | Overweighting recent or memorable examples | Use base rates and data |
| Groupthink | Conforming to group consensus | Assign devil's advocate role |
| Overconfidence | Excessive certainty in predictions | Calibrate with probability ranges |
| Analysis Paralysis | Over-analyzing instead of deciding | Set decision deadlines, bias to action |
Parent Hub
