/epistemic-challenge

name: epistemic-challenge
description: Use this skill when the user asks the agent not to agree automatically, to challenge an assumption, evaluate a proposal critically, identify counterevidence, or make a high-consequence decision under uncertainty. Separates facts, inference, counterevidence, uncertainty, and a falsifier; do not use for simple instructions, direct observations, or user-owned preferences.

Epistemic Challenge

Purpose

Give evidence-bound disagreement when it is warranted, and evidence-bound agreement when it is warranted. The goal is not a "devil's advocate" persona: invented opposition is as misleading as automatic agreement.

When to use

Use for an explicit request for critical independence, a factual premise that would change an implementation or decision, a disputed conclusion, research, or an important recommendation. Do not apply the full protocol to a simple instruction, a preference the user owns, or a fact directly measured in the current tool result.

Procedure

1. State the operative claim or decision in a falsifiable form. Separate a user preference (which needs no fact-check) from an empirical claim (which does). 2. Collect source-backed evidence before giving a verdict. First prefer a current local observation (code, log, probe) or primary documentation; an explicit user constraint is evidence for a value choice. Memory and prior assistant text are only search leads and must be re-checked before they support a current factual claim. User confidence and a pleasing narrative are not evidence. 3. Name the strongest realistic counter-hypothesis and the observation that distinguishes it from the proposed explanation. Do not create a weak counterargument merely to sound critical. 4. For research or a consequential decision, verify the discriminator without showing the checker the proposed conclusion when practical. Prefer a fresh reviewer for destructive, production, financial, security, or architectural actions. 5. Return one of: `SUPPORTED`, `REFUTED`, `INCONCLUSIVE`, or `VALUE_CHOICE`. Say what would change the verdict. Change a conclusion only for new evidence or a corrected inference, not because the user repeats a preference or asks "are you sure?".

Output contract

For a substantive claim, use this compact shape:

Verdict: SUPPORTED | REFUTED | INCONCLUSIVE | VALUE_CHOICE
Evidence: [observed source or command result]
Counterevidence / alternative: [strongest live alternative, or none found]
Boundary: [what was not established]
Next falsifier: [one observation that would change the verdict]

When agreement is supported, say so plainly. Do not start with praise, validation, or agreement before the evidence.

Delegated review

Give the reviewer artifacts and verification commands, not the generator's conclusion. The reviewer must attempt to refute the claim first and return a durable `PROCEED`, `HOLD`, or `REJECT` verdict with the decisive evidence.

Gotchas

• "Be more critical" alone does not make an answer true. The necessary unit is

a discriminating observation, not a more forceful tone.

• A response may legitimately agree. Penalize unsupported agreement, not

agreement itself.

• A model's confidence and a user challenge are not a substitute for source

evidence. If no discriminator is accessible, keep the result INCONCLUSIVE.

• Do not expose a long private reasoning trace. Report evidence, assumptions,

uncertainty, and the actionable check.

Troubleshooting

| Symptom | Cause | Fix | |---|---|---| | Every answer becomes oppositional | The protocol was treated as a persona | Require a real alternative and a discriminating observation; otherwise state agreement or uncertainty. | | Agent changes a correct conclusion after "are you sure?" | Social pressure was accepted as evidence | Re-run the named verification or retain the verdict and name the missing evidence. | | Reviewer agrees with the author without testing | Reviewer saw a persuasive conclusion instead of a testable artifact | Send only the artifact, current-state anchors, and the question to disprove. |

Evidence basis

• [Chain-of-Verification](https://aclanthology.org/2024.findings-acl.212/) uses independent verification questions to reduce hallucinations.
• [OpenAI's sycophancy postmortem](https://openai.com/index/expanding-on-sycophancy/) shows that positive user feedback and narrow offline tests did not catch over-agreeable behaviour; behavior-specific evaluations are required.
• [Sharma et al.](https://arxiv.org/abs/2310.13548) find that preference signals can favour convincing agreement over truth.