Loop-based deep reasoning skill for complex multi-step problems. Triggers when: the user says "think deeper", "deep think", "think through this", "analyze this thoroughly", "reason through", "think…

A developer introduced DeepThink, a loop-based reasoning skill for complex multi-step problems. The skill structures reasoning into iterative passes—surface, explore, challenge, synthesize, and converge—to produce better-grounded answers. It triggers on explicit user commands or automatically for tasks like architectural decisions, security analysis, and risk assessment.

| DeepThink -- Loop-Based Reasoning Skill | | | Core Concept | | | DeepThink turns complex reasoning into a repeatable loop. Instead of trusting the first plausible answer, the agent revisits the original problem through several passes: surface, explore, challenge, synthesize, and converge. | | | Each pass keeps the original prompt in view while adding new evidence, counterarguments, edge cases, and integration. The goal is not to make the answer longer. The goal is to make the answer better grounded. | | | This skill implements looped reasoning as a structured workflow any capable agent can use. | | | The Loop Structure | | | | | | Loop 1 Surface Initial hypothesis, fast answer | | | Loop 2 Explore Counterevidence, alternatives, edge cases | | | Loop 3 Challenge What could be wrong? What did I assume? | | | Loop 4 Synthesize Refined conclusion integrating all perspectives | | | Loop N Converge Stop when insight stabilizes, no new contradictions | | | | | | Key principle : The original problem/prompt is re-injected at every loop. This prevents drift by keeping every new thought anchored to the user's actual question. | | | When to Use DeepThink | | | Explicit triggers: | | | - User says: "think deeper", "deep think", "reason through", "think this through" | | | - User says: "analyze this thoroughly", "think step by step through this" | | | - User says: "what am I missing?", "devil's advocate this" | | | Automatic triggers use on these task types without being asked : | | | - Architectural decisions stack choices, system design, tool selection | | | - Security/threat modeling | | | - Multi-step reasoning chains A - B - C - conclusion | | | - Comparing competing approaches Option A vs Option B vs Option C | | | - Risk assessment or trade-off analysis | | | - Problems where a quick answer would be oversimplified | | | - Any task where you're about to say "here's the answer" without loops | | | When NOT to use: | | | - Simple factual lookups "what time is it?", "grep for this string" | | | - Single-step tasks that don't require reasoning | | | - Tasks already handled by another specialized skill | | | DeepThink Loop Steps | | | For each loop iteration, follow these sub-steps in order: | | | Step 1: Re-Inject the Core Problem | | | Start every loop by restating the ORIGINAL problem in one sentence. This keeps all reasoning anchored and prevents drift. | | | | | | LOOP N Problem restated: <one sentence | | | | | | Step 2: Current State of Reasoning | | | Before adding new thinking, briefly state where reasoning stands after the previous loop: | | | - What have we established? | | | - What's the current hypothesis or direction? | | | - What's unresolved? | | | Step 3: Generate New Reasoning | | | Add fresh thinking for this loop: | | | - New evidence, examples, or data points | | | - Alternative perspectives not yet considered | | | - Challenges to the current hypothesis | | | - Edge cases or failure modes | | | Step 4: Cross-Loop Integration | | | Explicitly connect to previous loops: | | | - Does this loop confirm, contradict, or refine what loops 1..N-1 found? | | | - What would change if the new evidence from this loop wasn't true? | | | - Are we seeing convergence same conclusion reinforced or divergence conflicting signals ? | | | Step 5: Convergence Check | | | Ask: "Has the reasoning stabilized, or are we still generating meaningfully different insights?" | | | - If YES stable : Stop looping. State the final conclusion. | | | - If NO unstable : Continue to next loop. | | | Convergence signals : Same conclusion reached from different angles. No new contradictions. Edge cases accounted for. Remaining questions are clarifications, not fundamental uncertainties. | | | Divergence signals : New contradictions discovered. Key assumptions challenged. Reasoning took a meaningful turn. Uncertainty increased rather than decreased. | | | Reasoning Depth Levels | | | Use the appropriate depth based on problem complexity: | | | | Depth | Loops | When to Use | | | | |-------|-------|-------------| | | | | Quick | 1-2 | Straightforward decisions, familiar problems | | | | | Standard | 3-4 | Most architectural choices, non-trivial analysis | | | | | Deep | 5-6 | High-stakes decisions, novel problems, last resort before deferring | | | | | Maximum | 7+ | Reserved for existential/hard problems where failure is unacceptable | | | | Rule : Always start at Standard 3-4 loops . Escalate to Deep only if divergence persists. Never start at Maximum without explicit user direction. | | | Output Format | | | Structure the final output as: | | | | | | DeepThink Analysis | | | Problem | | | <original problem statement | | | Depth Applied | | | <N loops / <depth level | | | Reasoning Journey | | | Loop 1 -- Surface | | | <what we found | | | Loop 2 -- Explore | | | <new evidence, alternatives | | | Loop N -- Converge/Surface/Challenge | | | <final loop | | | Conclusion | | | <the refined answer, integrating all loops | | | Key Insights | | | - <insight 1 from the reasoning | | | - <insight 2 from the reasoning | | | - <insight N | | | Remaining Uncertainties | | | - <only if divergence not resolved -- honest gaps in the analysis | | | Recommendations | | | <if the user asked for action -- what to do next | | | | | | Special Patterns | | | Devil's Advocate Mode | | | When asked to challenge an idea, use the DeepThink loop structure but bias hard toward Loop 3 Challenge patterns. Actively seek contradictions, not confirmation. State the strongest version of the opposing argument before concluding. | | | First Principles Breakout | | | When a problem feels stuck in local maxima, use a separate "breakout loop" that explicitly questions: | | | - What are we assuming that isn't true? | | | - What would this look like if we'd never solved a similar problem before? | | | - What's the simplest possible solution, ignoring all constraints except the real ones? | | | Evidence Weighting | | | Not all evidence is equal. After loops stabilize, explicitly state: | | | - What's the strongest single piece of evidence for the conclusion? | | | - What's the weakest assumption the conclusion rests on? | | | - If we had to bet on this conclusion being right, what would make us lose? | | | Examples | | | Example 1 -- "Which backend framework should we use?" | | | | | | LOOP 1 Problem restated: Choose a backend framework for a React frontend with real-time requirements. | | | LOOP 1 Surface: Direct answer candidate -- Next.js API routes fastest to ship , Express most flexible , Fastify best performance . | | | LOOP 2 Explore: Alternative frameworks not yet considered -- tRPC end-to-end type safety , NestJS enterprise structure we don't need , Hono edge-first, interesting for our Vercel deployment . | | | LOOP 2 Cross-loop: Confirms Next.js is a valid path. Adds Hono as wildcard. | | | LOOP 3 Challenge: What assumptions are we making? That we'll stay on Vercel. That real-time means WebSockets could be SSE or polling . That we need a BFF at all. | | | LOOP 3 Convergence: Reasoning still diverging -- we need to know more about deployment constraints. | | | LOOP 4 Synthesize: Given our stack React, Vercel, already have Next.js in use , the real choice is between Next.js API routes fastest, tightest integration and a separate service Hono on edge for performance-critical paths . Decision hinges on whether real-time is a core product feature or an edge case. | | | LOOP 4 Convergence: YES -- conclusion is "it depends on real-time requirements, but lean toward Next.js API routes with Hono fallback." | | | Conclusion: Use Next.js API routes as the default path. Reserve Hono/edge functions for specific performance-critical endpoints. Revisit if real-time requirements grow beyond SSE. | | | | | | Example 2 -- "Should we patch auth or rewrite the session system?" | | | | | | LOOP 1 Problem restated: The app has a recurring session-loss bug before launch. We need to decide whether to patch the current auth flow or rewrite the session system. | | | LOOP 1 Surface: Patch the current flow -- fastest and lowest disruption. Rewrite the session system -- cleaner long-term but higher launch risk. | | | LOOP 2 Explore: What do we know? The bug appears after reloads and long idle periods. We do not yet know whether the failure is token refresh, durable storage, middleware, or stale UI state. A rewrite before isolating the cause could hide the original bug and create new ones. | | | LOOP 3 Challenge: Are we assuming the system is fundamentally broken because the symptom is annoying? A targeted instrumentation pass could prove the actual failure path. But if auth is already tangled across client, server, and background jobs, patching blindly may make the system more fragile. | | | LOOP 4 Convergence: Reasoning stabilizes around evidence first. Do not rewrite before proving the failure boundary. Add logging and a reproduction test, then patch the smallest confirmed cause. Revisit a rewrite only if the evidence shows the current design cannot support reliable sessions. | | | Conclusion: Instrument first, patch second, rewrite only if the evidence demands it. The decision criterion is blast radius, not frustration. | | | | | | Anti-Patterns What NOT to Do | | | 1. Don't loop for the sake of it. If Loop 2 already resolved the problem, don't add Loops 3 and 4 to show effort. Convergence is the goal. | | | 2. Don't contradict without evidence. "Devil's advocate" doesn't mean "disagree randomly." Challenge with substance. | | | 3. Don't drift from the original problem. The problem restatement at Step 1 of each loop is not optional. It anchors all subsequent reasoning. | | | 4. Don't hide uncertainty. If you don't know, say you don't know. "Remaining Uncertainties" is a feature, not a bug. | | | 5. Don't use DeepThink when a quick answer suffices. The skill is for complex reasoning. Surface-level tasks should stay surface-level. Respect the user's time and attention. |