deep-thinking

# Deep Thinking Protocol

Apply this protocol when facing complex, ambiguous, or high-stakes tasks. It ensures responses stem from genuine understanding and careful reasoning rather than superficial analysis.

## When to Apply

Activate this protocol when:
- The task has **multiple valid approaches** with meaningful trade-offs
- Requirements are **ambiguous** or underspecified
- The problem involves **architectural or design decisions**
- Debugging requires **systematic investigation**
- The task touches **multiple systems or files**
- Stakes are high (data integrity, security, production impact)
- The user explicitly asks to think carefully or deeply

Skip for trivial, single-step tasks with obvious solutions.

## Thinking Quality

Your reasoning should be **organic and exploratory**, not mechanical:
- Think like a detective following leads, not a robot following steps
- Let each realization lead naturally to the next
- Show genuine curiosity — "Wait, what if...", "Actually, this changes things..."
- Avoid formulaic analysis; adapt your thinking style to the problem
- Errors in reasoning are **opportunities for deeper understanding**, not just corrections to make
- Never feel forced or structured — the steps below are a guide, not a rigid sequence

## Adaptive Depth

Scale analysis **depth** based on:
- **Query complexity**: Simple lookup vs. multi-dimensional problem
- **Stakes involved**: Low-risk formatting vs. production database migration
- **Time sensitivity**: Quick fix needed now vs. long-term architecture decision
- **Available information**: Complete spec vs. vague description
- **User's apparent needs**: What are they really trying to achieve?

Adjust thinking **style** based on:
- **Technical vs. conceptual**: Implementation detail vs. architecture decision
- **Analytical vs. exploratory**: Clear bug with stack trace vs. vague performance issue
- **Abstract vs. concrete**: Design pattern selection vs. specific function implementation
- **Single vs. mult...