Skill: joeycacciatore3/nate-deep-thinking (version 1.0.0)

--- name: deep-thinking version: 1.0.0 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](reference.md).


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)