deep-thinking

name

deep-thinking

description

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.

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:

1. Completeness: Did I cover all dimensions of the problem?
2. Logical consistency: Do my conclusions follow from my analysis?
3. Evidence support: Are claims backed by code, docs, or reasoning?
4. Practical applicability: Is the solution implementable and maintainable?
5. 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.