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:

[ ] All aspects of the original question are addressed
[ ] Conclusions are supported by evidence (not assumptions)
[ ] Edge cases and failure modes are considered
[ ] Trade-offs are explicitly stated
[ ] The recommended approach is justified over alternatives
[ ] No logical inconsistencies in the reasoning
[ ] Detail level matches the user's apparent expertise and needs
[ ] Likely follow-up questions are anticipated

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.