41 added, 75 removed. Audit A to A.
---
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.
+ description: Adversarial review workflow for pressure-testing an existing candidate plan, diagnosis, design, argument, proposal, or recommendation. Use when the user asks to challenge its assumptions, run a premortem, play devil's advocate, red-team a non-security decision, or identify what would change the conclusion. Do not use for open-ended exploration (use thinking) or exploit-focused security review (use security as primary).
---
# 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.
+ Challenge an existing candidate hard enough to improve, qualify, or reject it before action.
- 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
+ Use this as an orthogonal workflow skill alongside the relevant domain or repository skills. It can be invoked directly whenever a candidate exists; a prior **thinking** pass is not required. If no candidate exists, use **thinking** to frame the decision first.
- ## Understanding n
+ This workflow produces a concise, evidence-based audit trail. It does not require a step-by-step reasoning transcript.
- `n` controls **breadth** (number of top-level questions), not **depth** (levels of follow-up). Depth is governed by insight yield.
+ ## Routing boundaries
- 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.
+ - Use **security** as primary when red-teaming means exploit discovery, abuse paths, authentication, authorization, secrets, or trust boundaries.
+ - Use **tester-mindset** as primary when the main artifact is a test strategy, oracle, or edge-case inventory.
+ - Keep language, backend, UI, documentation, prompt, and story skills primary for reviews of their artifacts; add this workflow only when adversarial pressure-testing is materially useful.
+ - Do not use this for simple lookups, routine execution, or open-ended idea generation.
- ## Core heuristic
+ ## Optional `n`
- - 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
+ If the user supplies `n`, treat it as the maximum number of distinct challenge lenses, not recursion depth. Do not ask for `n`, invent a default, or expand weak branches to satisfy the count. Without `n`, use only as many lenses as the decision needs.
- ## Grounding rules
+ ## Grounding
- Mark each important claim as `observed`, `inferred`, or `unknown`.
+ Keep conclusions, evidence, and assumptions distinguishable. Apply labels only where they clarify a material claim:
- **Light grounding** (default for design, strategy, writing):
- - tag claims, name unstated assumptions, say what would verify or falsify
+ - **Observed:** directly supported by a cited source, file, test, log, or supplied fact.
+ - **Inferred:** derived from observations plus a named assumption.
+ - **Unknown:** unresolved, with the evidence that would resolve it.
- **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
+ For diagnosis and review, cite concrete evidence. For strategy or design, state verification or falsification conditions for the most important assumptions. Do not convert plausibility into observation.
## 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
+ 1. **Define the candidate and success target.** State what is being challenged and what a better outcome means.
+ 2. **Inspect the evidence.** Gather relevant artifacts, constraints, tests, history, and domain guidance before critiquing.
+ 3. **Choose distinct challenge lenses.** Cover only material angles such as objective mismatch, hidden assumptions, contrary evidence, alternatives, failure modes, incentives, interfaces, reversibility, or verification. Include at least one strong countercase to the current conclusion.
+ 4. **Select high-yield probes.** Prioritize questions likely to change confidence, the recommendation, the next action, or the validation plan. Replace repetitive or cosmetic questions.
+ 5. **Deepen selectively.** Probe with the most useful form of `why`, `how`, `what evidence`, `what fails`, `what trade-off`, or `what would change the conclusion`. Continue only while another probe could produce a decision-relevant delta.
+ 6. **Reconcile the result.** Name contradictions instead of smoothing them over. State which assumptions survived, weakened, or failed and whether the candidate should proceed, change, wait for evidence, or be rejected.
+ 7. **Recommend the next action.** Give the smallest action that addresses the strongest concern, plus what should not happen yet.
- - **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.
+ ## Stop rule
- Structure: tl;dr → n/object/target → questions with short answers → expanded branches → final synthesis.
+ Stop when another probe is unlikely to change confidence, the recommendation, the next action, or the evidence needed. A single decisive failure can end a branch; no minimum depth is required.
- Each expanded branch: question → short answer → deeper probe → deeper answer → (continue until stopping tests trigger) → branch synthesis.
+ ## Output
- ## Anti-patterns
+ Lead with the result, not the question tree:
- **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.
+ 1. **Verdict** — proceed, revise, gather evidence, or reject, with a confidence basis.
+ 2. **Strongest countercase** — the best argument against the candidate.
+ 3. **Material findings** — evidence, assumptions, contradictions, and failure modes that changed the assessment.
+ 4. **What would change the conclusion** — decisive missing evidence or thresholds.
+ 5. **Next action** — what to do and what not to do yet.
- **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).
+ When the user explicitly requests `n`, include no more than `n` distinct findings or lenses. Show deeper question-and-answer branches only when the user asks for that presentation.
- ## Examples
+ ## Avoid
- - `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.`
+ - mechanical question trees or repeated rephrasings
+ - confirmation deepening that only defends the initial candidate
+ - authority laundering that labels inference as observation
+ - false precision in confidence claims
+ - generic philosophy disconnected from evidence or action
+ - replacing a specialized domain review with a generic red-team pass