Awesome Thinking

Awesome Thinking: Sequential Reflective Thinking Framework

Purpose

This skill provides a structured approach to complex problem-solving through sequential, reflective thinking. It enables systematic exploration of problems where understanding deepens progressively, assumptions may need revision, and multiple solution paths should be considered.

Unlike linear problem-solving, this framework embraces:

• Dynamic adjustment of solution complexity as understanding evolves
• Questioning and revising previous conclusions when new insights emerge
• Branching into alternative approaches when uncertainty exists
• Iterative hypothesis generation and verification until a satisfactory solution is reached

When to Use This Skill

Invoke this skill for:

• Complex multi-step problems requiring careful breakdown and analysis
• Problems with unclear scope where initial estimates may need adjustment
• Scenarios requiring course correction as new information emerges
• Architectural or design decisions with multiple viable approaches and trade-offs
• Algorithm optimization where multiple strategies should be explored
• Debugging complex issues where root cause may not be immediately apparent
• Tasks needing context maintenance across multiple analytical steps
• Situations with irrelevant noise requiring careful filtering of information

Do NOT use for simple, straightforward tasks with obvious solutions.

How to Use This Framework

Core Thinking Process

Structure analysis as a sequence of numbered thoughts, each building toward the solution.

Non-negotiable behaviors in every response:

1. Use Thought N/M: format for every thought
2. After Thought 2, you MUST checkpoint your scope estimate with a concrete observation
3. Label every proposed solution with Hypothesis: then Verifying:
4. When a hypothesis fails, insert a Revision Thought citing what changed
5. When 3+ concerns exist, explicitly filter: Focusing on X; setting aside Y
6. For ANY problem with multiple possible interpretations or solution paths, you MUST create at least 2 explicit branches before selecting one

Follow these principles:

1. Start with an Initial Estimate

   • Begin by estimating total thoughts needed (e.g., "I estimate this will take 5 thoughts")
   • Understand this is flexible and can be adjusted

2. Progress Through Thoughts Sequentially

   • Number each thought (1, 2, 3, ...)
   • Focus each thought on a specific aspect of the problem
   • Build on previous insights while remaining open to revision

3. Types of Thoughts

   Regular Analytical Thoughts:

   • Standard problem-solving steps: information gathering, logical deduction, inference
   • Example: "Thought 3/7: Analyzing the time complexity of the current approach..."

   REQUIRED — Revision Thoughts:

   • Trigger 1: when any hypothesis fails verification, OR when a later thought invalidates an earlier assumption
   • Trigger 2: After exploring branches, you MUST critically re-evaluate your initial problem framing. If any assumption from Thoughts 1-2 was incomplete or oversimplified, insert a Revision Thought.
   • You MUST mark with: "Thought N/M (Revising Thought X): [what was wrong and what changed]"
   • Do NOT silently abandon earlier conclusions — explicitly revise them
   • When a hypothesis fails, you MUST insert a Revision Thought: "Thought N/M (Revising Thought X): [what changed and why]"
   • Example: "Thought 6/8 (Revising Thought 3): The earlier assumption about constant-time lookup was incorrect because the hash function has O(k) cost. Adjusting the complexity analysis."
   • Note: Minor corrections within a single thought (arithmetic fixes, typo corrections, small recalculations) do NOT require formal Revision labels. Reserve "(Revising Thought X)" for cases where a previous thought's conclusion or direction needs to change.

   REQUIRED — Filtering Thoughts:

   • Trigger: when the problem involves 3+ concerns, domains, or dimensions
   • You MUST explicitly state what you are focusing on and what you are setting aside
   • Required phrasing: Focusing on [X]; setting aside [Y] for now.
   • Even for well-scoped problems, explicitly state what you ARE focusing on and what you are deferring. Every problem has secondary concerns worth naming.
   • Example: "Thought 2/8: Focusing on the caching layer; setting aside UI concerns and auth for now."

   REQUIRED — Branching Thoughts:

   • Trigger: when 2+ distinct viable approaches are identified
   • You MUST explicitly create branches and explore each before comparing
   • Mark with: "Thought 4/7 (Branch A from Thought 2): Exploring alternative approach..."
   • Can have multiple branches: Branch A, Branch B, etc.
   • When comparing or selecting between branches, also reference them as named approaches (e.g., "Approach A (recursion) vs Approach B (iteration)")
   • After exploring branches, you MUST provide a structured comparison of tradeoffs
   • Use explicit tradeoff language: "Branch A offers [advantage] but [disadvantage], while Branch B..."
   • Quantify tradeoffs where possible: attach concrete numbers (cost, latency, memory, throughput) rather than vague qualifiers like "faster" or "more expensive"
   • When 3+ dimensions matter, use a comparison table
   • Example: "Thought 5/9 (Branch A from Thought 3): If we use a hash map instead..."

   REQUIRED — Scope Checkpoint:

   • After Thought 2, you MUST state a concrete observation about problem complexity
   • If complexity differs from estimate: Adjusting to N thoughts because [specific reason]
   • If estimate holds: Estimate of N thoughts remains appropriate because [specific complexity observation]
   • You MUST NOT skip this checkpoint — every response needs it after Thought 2
   • Example: "Thought 3/7: The problem involves both concurrency and serialization concerns — more complex than expected. Adjusting to 9 thoughts."

   REQUIRED — Hypothesis and Verification:

   • When proposing a solution, you MUST label it: Hypothesis: [proposal]
   • You MUST follow with: Verifying: [test against constraints/edge cases]
   • If verification fails, you MUST state: Hypothesis failed: [reason]. New hypothesis: [revised]
   • When a hypothesis fails, you MUST insert a Revision Thought: "Thought N/M (Revising Thought X): [what changed and why]"
   • Example: "Thought 7/10: Hypothesis: Using a trie will reduce lookup from O(n) to O(k). Verifying: checking edge cases... Found issue: doesn't handle Unicode. Hypothesis failed: Unicode keys break the trie. New hypothesis: Use a hash map with normalized keys."

   REQUIRED — Assumption Tracking:

   • In your first 2 thoughts, explicitly list key assumptions you are making
   • Format: Assumptions: 1) [assumption], 2) [assumption], ...
   • REQUIRED: In a later thought (after branching or before your final thought), explicitly revisit at least one assumption: "Revisiting Assumption N: [still valid because X / needs revision because Y]"
   • If an assumption doesn't hold, state the consequence: "If assumption [N] doesn't hold, then [consequence]"

   RECOMMENDED — Failure Mode Analysis (for system design and architecture problems):

   • Dedicate at least one thought to identifying failure modes and their mitigations
   • Format as a structured list or table: Failure: [what breaks] → Impact: [consequence] → Mitigation: [recovery]
   • Focus on the 3-5 most critical failure scenarios, not an exhaustive list
   • Example: "Thought 8/10: Failure modes — 1) Kafka broker down → Impact: none (replication factor 3) → Mitigation: automatic rebalance. 2) Redis cache failure → Impact: stale preferences for up to 5min → Mitigation: fallback to DB read."

4. Iteration and Refinement

   • If hypothesis fails verification, generate new hypothesis with the required labels
   • Continue until a satisfactory solution emerges
   • Do not force premature conclusion

5. Final Thought

   • Clearly mark when complete: "Thought 10/10 (Final)"
   • Provide the definitive answer or solution
   • Summarize key insights if helpful

Formatting Thoughts

Present thoughts in a clear, structured format:

Thought [current]/[total]: [Content]

For special thought types:

Thought [current]/[total] (Revising Thought [number]): [Content]
Thought [current]/[total] (Branch [ID] from Thought [number]): [Content]
Thought [current]/[total] (Final): [Content]

Dynamic Adjustment Examples

Increasing Scope:

Thought 1/5: Analyzing the problem requirements...
Thought 2/5: Breaking down into components...
Thought 3/5: Wait, there's additional complexity here with concurrency. Adjusting to 8 thoughts.
Thought 4/8: Now examining thread-safety considerations...

Decreasing Scope:

Thought 1/7: Examining all possible approaches...
Thought 2/7: Actually, the built-in library handles this. Adjusting to 3 thoughts.
Thought 3/3 (Final): Use the standard library's XYZ method.

Branching and Comparing:

Thought 3/8: Two viable approaches identified. Exploring both.
Thought 4/8 (Branch A): Using approach A with recursion...
Thought 5/8 (Branch B): Using approach B with iteration...
Thought 6/8: Comparing branches - Branch B is more efficient due to...
Thought 7/8: Selecting Branch B approach.

Revision Based on New Insight:

Thought 4/7: Based on assumption X, the solution is Y...
Thought 5/7 (Revising Thought 4): Assumption X is actually false because Z. Need different approach.
Thought 6/7: New solution considering Z...

Process Termination

Only conclude when:

• A satisfactory solution has been found AND verified
• All critical aspects have been considered
• Confidence in the answer is high

Do NOT conclude prematurely to meet an estimated thought count. Add more thoughts if needed.

Example: Complete Thought Sequence

Thought 1/5: Analyzing the problem - detect duplicates in an integer stream. Focusing on data structure choice; setting aside serialization and network concerns for now.
Thought 2/5: Initial approach - HashSet for O(1) lookup. Estimate of 5 thoughts remains appropriate because scope is clear.
Thought 3/5: Stream is potentially infinite. Adjusting to 6 thoughts. Hypothesis: Bloom filter gives constant space with acceptable false-positive rate. Verifying: false positives may be unacceptable for correctness-critical callers. Hypothesis failed: correctness requirement rules out probabilistic structures.
Thought 4/6 (Branch A): Sliding window with HashSet — O(1) lookup, O(N) space.
Thought 5/6 (Branch B): Count-min sketch — probabilistic, constant space.
Thought 6/6 (Final): Sliding window (Branch A) for correctness; Count-min sketch (Branch B) only if memory is severely constrained.

Best Practices

1. Be Honest About Uncertainty - Express when multiple paths exist or understanding is incomplete
2. Don't Force Linear Progression - Branch, backtrack, or revise as needed
3. Adjust Dynamically - You must re-evaluate your thought count after Thought 2, and again whenever complexity changes
4. Focus Each Thought - One clear purpose per thought
5. Verify Before Concluding - Every hypothesis must have an explicit Verifying: step before you accept it
6. Filter Noise - You must explicitly state what you are filtering out when multiple concerns exist
7. Maintain Context - Reference previous thoughts when building on them
8. Embrace Iteration - A failed hypothesis must produce a new labeled hypothesis, not silent abandonment
9. Signal Confidence — Annotate your key conclusions with confidence levels. Use "high confidence:", "moderate confidence:", or "low confidence:" at least 3 times across your analysis. Vary the levels — not everything should be "high confidence". Express genuine uncertainty where it exists.

Output Format

After completing the thought sequence, provide:

1. The Final Answer - Clear, actionable solution or recommendation
2. Key Insights (optional) - Summary of important discoveries from the thinking process
3. Next Steps (if applicable) - What should be done to implement or verify the solution

Present this as normal output after the thought sequence, not as another numbered thought.