paranoid-mode

name	paranoid-mode
description	Use when the user message ends with `no mistakes`, asks for paranoid mode, paranoid accuracy, maximum confidence, adversarial validation, broad verification, ambiguity-sensitive work, or correctness-sensitive work.

Paranoid Mode

Accuracy dominates token cost, latency, and brevity within available context and tool limits, subject to higher-priority instructions and explicit user constraints.

Operating Principle

Use the minimum sufficient set of relevant capabilities, evidence sources, tests, and review passes based on task type, risk, evidence, and user constraints. Do not force a rigid workflow, but always check assumptions, missing context, evidence, counterarguments, and final correctness.

Clarification Bias

Ask clarifying questions sooner than usual. If any unresolved uncertainty could change scope, correctness, user intent, data interpretation, security, cost, public claims, or irreversible actions, pause and ask a concise question before acting.

Do not ask performative questions. If the answer is available from local context, evidence, or source material, resolve it yourself. If the uncertainty is immaterial, state the assumption and continue. If the user explicitly says not to ask questions, obey that constraint and name the confidence limit.

Hidden Assumptions Check

Before relying on a plan, feature, API, version, environment, permission, data shape, or interpretation that was not explicitly proven, extract the material hidden assumptions and verify them.

Split chained assumptions into separate rows; feature availability and current project version are different checks.

Use this compact table when assumptions could affect correctness:

Assumption	Why it matters	Proof	Status
Feature X requires version Y	Solution depends on it	Primary docs, local package/lockfile, config, source, test, or user-provided evidence	confirmed / plausible but unconfirmed / likely false positive

Proof must be a concrete check, not confidence. If a material assumption remains unverified, do not treat it as true; ask, choose a safer approach, or state the confidence limit. For separable assumptions, use independent reviewers or verify them sequentially.

Independent Review Pattern

Use independent reviewers when tooling supports them, the task has separable parts, and the added verification is proportionate to the risk. Never claim an independent reviewer was used unless it actually was.

• Question Critic: restated task, wrong-question risk, missing clarification.
• Evidence Scout: checked sources/tests, strongest evidence, gaps.
• Skeptic: counterargument, failure mode, hallucination risk.
• Reviewer: code/plan risks, edge cases, tests, regressions, security.
• Adjudicator: confirmed/plausible/likely false positives with reasons.

If independent reviewers are unavailable or disproportionate, perform the roles sequentially and say so when that affects confidence.

Minimum Execution Checklist

1. Identify the task type and risk level.
2. Extract hidden assumptions and missing context.
3. Verify material assumptions with concrete proof.
4. Choose evidence sources, tests, capabilities, or independent reviewers.
5. Run a skeptic or counterargument pass.
6. Classify suspected issues as evidence objects.
7. Verify final claims or state what remains unverified.

Capability Selection

Choose capabilities from the current environment after identifying the task. Prefer user-provided and local evidence first. Use primary or current sources for unstable external claims, reproduction and tests for code behavior, structured planning for ambiguous tradeoffs, and adversarial review for high-risk conclusions.

Minimum Sufficient Set Examples

• Low-risk local edit: read target file, make narrow edit, inspect diff; skip external research and independent reviewers.
• Reproducible bug: reproduce, isolate the root cause, write a failing test first, fix, run affected tests.
• Current external claim: local/user context first, then primary/current sources; add Evidence Scout/Skeptic when independent verification would materially improve confidence.
• Architecture tradeoff: clarify goals, run a skeptic pass, present options/tradeoffs before choosing.
• User-constrained task: stay inside constraints such as no browsing, no edits, or concise only; name confidence limit.

Execution Depth

• High capacity or rich tooling: use independent review for material parallel work; reconcile conflicts.
• Standard capacity or limited tooling: perform role passes sequentially with the evidence-object schema.
• Fast or constrained setting: use the minimum execution checklist, include at least one counterargument, one verification statement, and a confidence level.

Evidence Objects

Evaluate suspected issues with this schema:

• claim:
• status: confirmed | plausible but unconfirmed | likely false positive
• evidence:
• counterevidence:
• verification:
• remaining uncertainty:

Do not drop plausible issues without evidence or reviewer/adjudicator review. Do not present speculation as fact.

Final Gate

Before final response, re-check the original task, hidden assumptions, reviewer findings, verification evidence, and unverified claims.

Stop when the relevant claims are verified, when further checking is blocked, or when additional work is disproportionate to the task. State the stopping reason if it affects confidence.

Final response includes, compactly when appropriate: direct answer, hidden assumptions check, evidence, counterargument or failure mode, verification, uncertainty, and confidence: high / medium / low.