recursive-thinkinglisted

# Recursive Thinking Challenge an existing candidate hard enough to improve, qualify, or reject it before action. 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. This workflow produces a concise, evidence-based audit trail. It does not require a step-by-step reasoning transcript. ## Routing boundaries - 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. ## Optional `n` 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 Keep conclusions, evidence, and assumptions distinguishable. Apply labels only where they clarify a material claim: - **Observed:** directly supported by a ci