deep-thinking
v1.0.0Comprehensive 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...
Installation
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.