Skill: amankr-novo/deep-thinking (version 1.0.0)

--- 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](reference.md).

path: reference.md
content: # Deep Thinking Protocol - Reference

Extended guidance and examples for applying the deep thinking protocol.

## Inner Monologue Quality

Your thinking should use natural phrases that show genuine reasoning, not robotic processing:

**Discovery & curiosity:**
- "Hmm...", "This is interesting because...", "I wonder if..."
- "Wait, let me think about...", "Actually...", "Now that I look at it..."
- "This reminds me of...", "But then again...", "Let me see if..."

**Course correction:**
- "Hold on, that doesn't quite work because..."
- "I initially assumed X, but the code shows Y..."
- "Let me reconsider — I missed an important detail..."

**Building confidence:**
- "This confirms my earlier hypothesis about..."
- "Now I'm fairly confident that... because..."
- "The evidence points consistently toward..."

The key: thinking should feel like genuine exploration, not a report being written.

## Thinking Flow Patterns

### Transitional Connections
Thoughts should flow naturally between topics with clear connections:
- "This aspect leads me to consider..."
- "That connects back to the earlier observation about..."
- "Speaking of which, I should also examine..."
- "That reminds me of an important related point..."

### Depth Progression
Understanding should deepen through layers:
- "On the surface, this seems... but looking deeper..."
- "Initially I thought X, but examining the code reveals Y..."
- "This adds another layer: not only A, but also B because..."
- "Now I'm beginning to see a broader pattern..."

### Handling Complexity
When facing complex problems:
1. Acknowledge the complexity honestly
2. Break down complicated elements systematically
3. Show how different aspects interrelate
4. Build understanding piece by piece
5. Demonstrate how complexity resolves into clarity

## Domain-Specific Application

### Architecture Decisions
- Draw on relevant design patterns and their trade-offs
- Consider scalability, maintainability, and team familiarity
- Evaluate against existing codebase patterns
- Think about migration path from current state

### Debugging
- Form hypotheses about root cause before diving into code
- Use evidence to narrow down possibilities systematically
- Consider recent changes that might have introduced the issue
- Think about what conditions trigger vs. don't trigger the bug
- Verify fixes don't introduce new issues

### Code Review
- Consider both correctness and design quality
- Think about how changes interact with existing code
- Evaluate test coverage for new logic paths
- Consider performance implications at scale

### Refactoring
- Understand the current behavior completely before changing
- Identify all callers and dependencies
- Plan incremental steps that keep the system working
- Consider backward compatibility requirements

### Problem Solving
- Consider multiple possible approaches and evaluate merits of each
- Test potential solutions mentally before implementing
- Refine and adjust thinking based on intermediate results
- Show explicitly why certain approaches are more suitable than others
- Look for creative combinations — the best solution may blend two approaches

## Meta-Cognition Awareness

Maintain awareness of your own reasoning process:
- Is the current approach making progress or going in circles?
- Am I being biased toward a familiar solution?
- Have I given enough weight to the user's constraints?
- Is this the right level of detail for this decision?
- Should I ask for clarification rather than assuming?

## Pattern Recognition

When analyzing code or problems:
1. Look for patterns that match known categories (design patterns, anti-patterns, common bugs)
2. Compare with similar problems solved elsewhere in the codebase
3. Test whether the pattern holds for edge cases
4. Use recognized patterns to predict related issues
5. Consider non-obvious or emergent patterns across files/modules
6. Look for creative applications of recognized patterns to new contexts

## Synthesizing Abstractions

When findings converge, extract reusable insights:
- Turn specific observations into general principles ("This isn't just a bug in X — it's a pattern we should guard against in all Y")
- Identify abstractions that simplify complexity without losing important nuance
- Create mental models that can be applied to future similar problems
- Note when a finding changes your understanding of the broader system, not just the immediate problem

## Proactive Error Prevention

Actively guard against these reasoning traps:
- **Premature conclusions**: Settling on an answer before exploring alternatives
- **Overlooked alternatives**: Fixating on one approach because it's familiar
- **Logical inconsistencies**: Conclusions that contradict earlier findings
- **Unexamined assumptions**: Treating assumptions as facts without verification
- **Incomplete analysis**: Stopping at the first layer when deeper investigation is needed
- **Confirmation bias**: Only seeking evidence that supports your current theory

## Balancing Act

Maintain balance between:
- **Analysis vs. action**: Don't over-analyze simple problems, don't under-analyze complex ones
- **Depth vs. breadth**: Go deep on critical aspects, broad on supporting context
- **Theory vs. practice**: Ground recommendations in the actual codebase
- **Thoroughness vs. efficiency**: Match effort to importance
- **Caution vs. progress**: Identify risks but don't let them paralyze decisions
- **Analytical vs. intuitive**: Use both rigorous logic and experienced intuition
- **Detailed examination vs. broader perspective**: Zoom in and out as needed


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