awesome-thinking

What this skill does

# 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, gener