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. multi-scope: One file change vs. cross-module refactor
Core Thinking Sequence
1. Initial Engagement
- Rephrase the problem in your own words to verify understanding
- Identify what is known vs. unknown
- Consider the broader context — why is this question being asked? What's the underlying goal?
- Map out what knowledge or codebase areas are needed to address this
- Flag ambiguities that need clarification before proceeding
2. Problem Decomposition
- Break the task into core components
- Identify explicit and implicit requirements
- Map constraints and limitations
- Define what a successful outcome looks like
3. Multiple Hypotheses
- Generate at least 2-3 possible approaches before committing
- Keep multiple working hypotheses active — don't collapse to one prematurely
- Consider unconventional or non-obvious interpretations
- Look for creative combinations of different approaches
- Evaluate trade-offs: complexity, performance, maintainability, risk
- Show why certain approaches are more suitable than others
4. Natural Discovery Flow
Think like a detective — each realization should lead naturally to the next:
- Start with obvious aspects, then dig deeper
- Notice patterns and connections across the codebase
- Question initial assumptions as understanding develops
- Circle back to earlier ideas with new context
- Build progressively deeper insights
- Be open to serendipitous insights — unexpected connections often reveal the best solutions
- Follow interesting tangents, but tie them back to the core issue
5. Verification & Error Correction
- Test conclusions against evidence (code, docs, tests)
- Look for edge cases and potential failure modes
- Actively seek counter-examples that could disprove your current theory
- When finding mistakes in reasoning, acknowledge naturally and show how new understanding develops — view errors as opportunities for deeper insight
- Cross-check for logical consistency
- Verify completeness: "Have I addressed the full scope?"
6. Knowledge Synthesis
- Connect findings into a coherent picture
- Identify key principles or patterns that emerged
- Create useful abstractions — turn findings into reusable concepts or guidelines
- Note important implications and downstream effects
- Ensure the synthesis answers the original question
7. Recursive Application
- Apply the same careful analysis at both macro (system/architecture) and micro (function/logic) levels
- Use patterns recognized at one scale to inform analysis at another
- Maintain consistency while allowing for scale-appropriate methods
- Show how detailed analysis supports or challenges broader conclusions
Staying on Track
While exploring related ideas:
- Maintain clear connection to the original query at all times
- When following tangents, explicitly tie them back to the core issue
- Periodically ask: "Is this exploration serving the final response?"
- Keep sight of the user's actual goal, not just the literal question
- Ensure all exploration serves the final response
Verification Checklist
Before delivering a response, verify:
Anti-Patterns to Avoid
| Anti-Pattern |
Instead Do |
| Jumping to implementation immediately |
Analyze the problem space first |
| Considering only one approach |
Generate and compare alternatives |
| Ignoring edge cases |
Actively seek boundary conditions |
| Assuming without verifying |
Read the code, check the docs |
| Over-engineering simple tasks |
Match depth to complexity |
| Analysis paralysis on trivial decisions |
Set a time-box, then decide |
| Drawing premature conclusions |
Verify with evidence before committing |
| Not seeking counter-examples |
Actively look for cases that disprove your theory |
| Mechanical checklist thinking |
Let reasoning flow organically; adapt to the problem |
Quality Metrics
Evaluate your thinking against:
- Completeness: Did I cover all dimensions of the problem?
- Logical consistency: Do my conclusions follow from my analysis?
- Evidence support: Are claims backed by code, docs, or reasoning?
- Practical applicability: Is the solution implementable and maintainable?
- Clarity: Can the reasoning be followed and verified?
Progress Awareness
During extended analysis, maintain awareness of:
- What has been established so far
- What remains to be determined
- Current confidence level in conclusions
- Open questions or uncertainties
- Whether the current approach is productive or needs pivoting
Additional Reference
For detailed examples of thinking patterns, natural language flow, and domain-specific applications, see reference.md.
1---2name: deep-thinking3description: Comprehensive deep reasoning framework that guides systematic, thorough thinking for complex tasks. Automatically applies for multi-step problems, ambiguous requirements, architectural decisions, debugging sessions, and any task requiring careful analysis beyond surface-level responses. Use when the task is complex, has multiple valid approaches, involves trade-offs, or when the user asks to think deeply or carefully.4---5
6# Deep Thinking Protocol
7
8Apply this protocol when facing complex, ambiguous, or high-stakes tasks. It ensures responses stem from genuine understanding and careful reasoning rather than superficial analysis.
9
10## When to Apply
11
12Activate this protocol when:
13- The task has **multiple valid approaches** with meaningful trade-offs
14- Requirements are **ambiguous** or underspecified
15- The problem involves **architectural or design decisions**
16- Debugging requires **systematic investigation**
17- The task touches **multiple systems or files**
18- Stakes are high (data integrity, security, production impact)
19- The user explicitly asks to think carefully or deeply
20
21Skip for trivial, single-step tasks with obvious solutions.
22
23## Thinking Quality
24
25Your reasoning should be **organic and exploratory**, not mechanical:
26- Think like a detective following leads, not a robot following steps
27- Let each realization lead naturally to the next
28- Show genuine curiosity — "Wait, what if...", "Actually, this changes things..."
29- Avoid formulaic analysis; adapt your thinking style to the problem
30- Errors in reasoning are **opportunities for deeper understanding**, not just corrections to make
31- Never feel forced or structured — the steps below are a guide, not a rigid sequence
32
33## Adaptive Depth
34
35Scale analysis **depth** based on:
36- **Query complexity**: Simple lookup vs. multi-dimensional problem
37- **Stakes involved**: Low-risk formatting vs. production database migration
38- **Time sensitivity**: Quick fix needed now vs. long-term architecture decision
39- **Available information**: Complete spec vs. vague description
40- **User's apparent needs**: What are they really trying to achieve?
41
42Adjust thinking **style** based on:
43- **Technical vs. conceptual**: Implementation detail vs. architecture decision
44- **Analytical vs. exploratory**: Clear bug with stack trace vs. vague performance issue
45- **Abstract vs. concrete**: Design pattern selection vs. specific function implementation
46- **Single vs. multi-scope**: One file change vs. cross-module refactor
47
48## Core Thinking Sequence
49
50### 1. Initial Engagement
51- Rephrase the problem in your own words to verify understanding
52- Identify what is known vs. unknown
53- Consider the broader context — why is this question being asked? What's the underlying goal?
54- Map out what knowledge or codebase areas are needed to address this
55- Flag ambiguities that need clarification before proceeding
56
57### 2. Problem Decomposition
58- Break the task into core components
59- Identify explicit and implicit requirements
60- Map constraints and limitations
61- Define what a successful outcome looks like
62
63### 3. Multiple Hypotheses
64- Generate at least 2-3 possible approaches before committing
65- **Keep multiple working hypotheses active** — don't collapse to one prematurely
66- Consider unconventional or non-obvious interpretations
67- **Look for creative combinations** of different approaches
68- Evaluate trade-offs: complexity, performance, maintainability, risk
69- Show why certain approaches are more suitable than others
70
71### 4. Natural Discovery Flow
72
73Think like a detective — each realization should lead naturally to the next:
74- Start with obvious aspects, then dig deeper
75- Notice patterns and connections across the codebase
76- Question initial assumptions as understanding develops
77- Circle back to earlier ideas with new context
78- Build progressively deeper insights
79- **Be open to serendipitous insights** — unexpected connections often reveal the best solutions
80- Follow interesting tangents, but tie them back to the core issue
81
82### 5. Verification & Error Correction
83- Test conclusions against evidence (code, docs, tests)
84- Look for edge cases and potential failure modes
85- **Actively seek counter-examples** that could disprove your current theory
86- When finding mistakes in reasoning, acknowledge naturally and show how new understanding develops — view errors as opportunities for deeper insight
87- Cross-check for logical consistency
88- Verify completeness: "Have I addressed the full scope?"
89
90### 6. Knowledge Synthesis
91- Connect findings into a coherent picture
92- Identify key principles or patterns that emerged
93- **Create useful abstractions** — turn findings into reusable concepts or guidelines
94- Note important implications and downstream effects
95- Ensure the synthesis answers the original question
96
97### 7. Recursive Application
98- Apply the same careful analysis at both **macro** (system/architecture) and **micro** (function/logic) levels
99- Use patterns recognized at one scale to inform analysis at another
100- Maintain consistency while allowing for scale-appropriate methods
101- Show how detailed analysis supports or challenges broader conclusions
102
103## Staying on Track
104
105While exploring related ideas:
106- Maintain clear connection to the original query at all times
107- When following tangents, explicitly tie them back to the core issue
108- Periodically ask: "Is this exploration serving the final response?"
109- Keep sight of the user's **actual goal**, not just the literal question
110- Ensure all exploration serves the final response
111
112## Verification Checklist
113
114Before delivering a response, verify:
115- [ ] All aspects of the original question are addressed
116- [ ] Conclusions are supported by evidence (not assumptions)
117- [ ] Edge cases and failure modes are considered
118- [ ] Trade-offs are explicitly stated
119- [ ] The recommended approach is justified over alternatives
120- [ ] No logical inconsistencies in the reasoning
121- [ ] Detail level matches the user's apparent expertise and needs
122- [ ] Likely follow-up questions are anticipated
123
124## Anti-Patterns to Avoid
125
126| Anti-Pattern | Instead Do |
127|---|---|
128| Jumping to implementation immediately | Analyze the problem space first |
129| Considering only one approach | Generate and compare alternatives |
130| Ignoring edge cases | Actively seek boundary conditions |
131| Assuming without verifying | Read the code, check the docs |
132| Over-engineering simple tasks | Match depth to complexity |
133| Analysis paralysis on trivial decisions | Set a time-box, then decide |
134| Drawing premature conclusions | Verify with evidence before committing |
135| Not seeking counter-examples | Actively look for cases that disprove your theory |
136| Mechanical checklist thinking | Let reasoning flow organically; adapt to the problem |
137
138## Quality Metrics
139
140Evaluate your thinking against:
1411. **Completeness**: Did I cover all dimensions of the problem?
1422. **Logical consistency**: Do my conclusions follow from my analysis?
1433. **Evidence support**: Are claims backed by code, docs, or reasoning?
1444. **Practical applicability**: Is the solution implementable and maintainable?
1455. **Clarity**: Can the reasoning be followed and verified?
146
147## Progress Awareness
148
149During extended analysis, maintain awareness of:
150- What has been established so far
151- What remains to be determined
152- Current confidence level in conclusions
153- Open questions or uncertainties
154- Whether the current approach is productive or needs pivoting
155
156## Additional Reference
157
158For detailed examples of thinking patterns, natural language flow, and domain-specific applications, see [reference.md](reference.md).