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.
Scanned 5/28/2026
Install via CLI
openskills install n-n-code/n-n-code-skills---
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.`
No comments yet. Be the first to comment!