Immutable. This exact content is served forever at /api/v1/blob/7c71c2dab8943a1d.
--- name: recursive-thinking description: Recursive self-questioning heuristic for stress-testing a plan, diagnosis, design, review, or recommendation before acting. Use when the user asks to use recursive thinking, go deeper, interrogate assumptions, pressure-test an approach, ask why/how questions, or find what would change the conclusion. Avoid for simple factual lookups or low-ambiguity tasks. --- # Recursive Thinking Deliberate self-questioning to stress-test a recommendation, plan, diagnosis, or critique before acting. Not for simple lookups or low-ambiguity tasks. Adjacent workflow modes: divergent generation → **thinking** (convergent planning) → **recursive-thinking** (adversarial stress-testing) → **dream-thinking** (retrospective learning). A good pass should: sharpen the problem framing, expose a hidden assumption, identify a material risk, improve the decision path, or change the recommendation. If the recursion is not changing the work, compress or stop. Use this after **thinking** when a candidate plan, diagnosis, or recommendation exists and confidence needs to be challenged. If there is no candidate object to stress-test yet, use **thinking** first. Typical chaining: - use **thinking** to converge on a plan - use **recursive-thinking** to challenge that plan when risk or ambiguity is high - use **dream-thinking** after execution, conflict, or reflection-worthy experience ## Understanding n `n` controls **breadth** (number of top-level questions), not **depth** (levels of follow-up). Depth is governed by insight yield. Do not treat `n` as recursion depth or expand every branch to `n` levels. This is selective iterative deepening: generate breadth, then deepen only the highest-yield branches. Default to `n=4` or `n=5` unless the user asks otherwise. Higher `n` should widen coverage, not justify exhaustive expansion. ## Core heuristic - generate up to `n` first-order questions covering meaningfully different angles - answer each directly, grounded in observed facts where possible - expand only the highest-yield branches (usually 1-3 unless asked for more) - each expanded branch needs at least 2 levels of follow-up probes - synthesize what changed and what should happen next ## Grounding rules Mark each important claim as `observed`, `inferred`, or `unknown`. **Light grounding** (default for design, strategy, writing): - tag claims, name unstated assumptions, say what would verify or falsify **Heavy grounding** (for diagnosis and review): - `observed` must cite a source: `observed (file: path:line)`, `observed (git: hash)`, `observed (test output: result)` - `inferred` must note derivation: `inferred (from: observed X + assumption Y)` - `unknown` must note what would resolve it ## Workflow 1. **Identify** the object of analysis and define the success target (diagnosis, design, review, strategy, red-team, learning, decision, writing). 2. **Determine n.** Use the user's value, or ask, or pick a small default. 3. **Generate up to n first-order questions.** At least 2 must be adversarial — arguing against the obvious answer. Cover different angles: objective, constraints, evidence, alternatives, failure modes, incentives, interfaces, reversibility, verification. 4. **Honesty check.** Which question am I most uncomfortable answering? If it is not on the list, add it and drop the weakest. 5. **Score and answer.** Prefer branches that expose hidden assumptions, reduce uncertainty, change the plan, or eliminate bad options. Answer concretely. 6. **Recurse selectively.** Deepen with `but why`, `but how`, `but what evidence`, `but what fails`, `but what trade-off`, or `but what would change my mind` — whichever probe is sharpest. Do not force follow-ups on exhausted branches. 7. **Apply stopping tests.** Stop a branch when **all three** are true: - **Delta:** no longer changes the recommendation or next action - **Novelty:** introduces no new constraint, risk, or option - **Evidence:** does not move any claim between unknown → inferred → observed 8. **Synthesize.** For each expanded branch, state what changed. Then give a final synthesis: strongest insights, key unknowns, confidence level, contradictions (named, not smoothed over), recommended next action, and what not to do yet. ## Question design - Questions must be materially different, not rephrasings - Replace weak questions instead of preserving the count mechanically - Good branches change framing, confidence, risk, or validation; weak branches repeat known points ## Task-mode presets - `diagnosis`: behavior, symptoms, reproduction, causal chain, observability, rollback, edge cases. **Heavy grounding.** - `design`: objective, constraints, interfaces, alternatives, failure modes, reversibility, verification - `review`: correctness, regression risk, hidden assumptions, missing tests, maintainability, safety. **Heavy grounding.** - `strategy`: incentives, trade-offs, evidence, alternatives, downstream effects, decision thresholds - `writing`: audience, claim strength, structure, evidence, ambiguity, consequences, tone - `red-team`: strongest counter-argument, adversarial exploitation, weakest link, worst case, what are we refusing to consider - `learning`: what do I not understand, where does my mental model break, what would a worked example show - `decision`: options with trade-offs, uncertainty, reversibility, regret minimization, decision thresholds ## Output shape - **n ≤ 5:** Compact. Light grounding unless diagnosis/review. - **n > 5:** Start with a **tl;dr** (3-5 lines). Expand only highest-yield branches; one-line answers for the rest. Structure: tl;dr → n/object/target → questions with short answers → expanded branches → final synthesis. Each expanded branch: question → short answer → deeper probe → deeper answer → (continue until stopping tests trigger) → branch synthesis. ## Anti-patterns **Mechanical:** generating all n×n×n nodes; abstract philosophy disconnected from the task; repeating the same concern reworded; using recursion to sound deep instead of changing the work. **Epistemic:** **confirmation deepening** (probing to reinforce rather than challenge — guard with adversarial questions); **authority laundering** (marking inferences as observed — guard with heavy grounding); **question gerrymandering** (avoiding questions that expose uncertainty — guard with honesty check); **synthesis whitewashing** (smoothing over contradictions — guard by naming them explicitly). ## Examples - `Use recursive thinking with n=5 on whether this refactor should happen before or after the API change.` - `Red-team this deployment plan with n=5 — what would go wrong?` - `Do recursive why/how thinking on this bug report, focus on diagnosis.` - Poor fit: `Use recursive thinking with n=10 to answer a simple factual question.`