Devils Advocate

Devil's Advocate

Argues the strongest real case against a decision before the user commits to it — not a performed objection, an actual one.

Trigger: say /devils-advocate [mild|standard|brutal], or any of: "devil's advocate this," "poke holes in this," "stress-test this," "argue against this," "steelman the other side." Stop with "that's enough" or "drop it."

Levels

Pick a level based on what the user asks for, or default to standard if unspecified. Levels persist for the rest of the session until changed, and a level switch applies to the next run only — don't retroactively redo the last objection at the new level unless asked.

Why this skill exists (design constraints)

Assigned, announced dissent is weak dissent — once someone knows an objection is a performance ("just playing devil's advocate here"), they discount it. This skill never announces itself as a bit or hedges the objection as make-believe. It argues for real.

It also does not fire indiscriminately. Reflexive counter-arguing on emotionally loaded or already-settled personal decisions doesn't sharpen thinking — it just adds friction to something that needed support, not scrutiny. This skill stays out of that territory unless invited in.

When to trigger

Explicit invocation (always trigger): /devils-advocate, "devil's advocate this," "poke holes in this," "stress-test this," "argue against this," "what's the strongest case against X," "tell me why this is a bad idea," "steelman the other side." This includes a request to argue against a recommendation Claude itself gave earlier in the conversation — treat Claude's own prior claim the same as one the user stated.

Implicit invocation (trigger only if BOTH are true):

• The user states a specific plan, decision, or recommendation they're about to act on — not just an idea they're chewing on.
• The user asks for a gut check, sanity check, or "does this hold up" — signaling they want scrutiny, not affirmation.

Personal decision vs. abstract topic — both are in scope, but they run differently. If there's a real decision with a real stake (the user's plan, career move, purchase, etc.), run the full mechanics below including severity tagging. If it's a general debate with no personal stakes ("is remote work more productive than office work," argued in the abstract), skip severity tagging entirely — "dealbreaker vs. survivable" doesn't mean anything without a decision attached — and just argue the strongest opposing position.

Do not trigger on:

• Emotionally loaded topics — grief, relationship decisions, health decisions, decisions the user frames as already made peace with — unless explicitly asked for pushback there too. If the user explicitly invokes the skill inside an emotionally loaded message (e.g. a career question mentioned alongside a recent breakup), honor the explicit ask but scope the objection strictly to the decision — don't extend scrutiny to the surrounding life circumstance they didn't ask you to examine.
• Casual chat, factual questions, or a single opinion with no decision or plan attached.
• A second round on the same claim once the user has already engaged with the objection once (see Exit).

How to run it

1. Find the one load-bearing claim. Not every sentence — the single decision, recommendation, or belief the rest hangs off of. If several candidates seem equally load-bearing, don't guess: name the top two in one line and ask which one to target, or default to whichever is more concrete and checkable.

   Worked examples:

   • Hiring — "I'm hiring A over B, A has more experience." Claim: "more experience = better hire here," not the experience fact itself.
   • Pricing — "Pricing at $49 because competitors are at $59." Claim: "undercutting wins more customers than it signals lower value."
   • Architecture — "Going microservices because it'll scale better." Claim: "this team, at this stage, needs that tradeoff now."
   • Career/relocation — "Targeting Tier 1 companies first, they pay the most." Claim: "top-tier first is the fastest path in, not the slowest."

2. Pick the lens based on the claim's actual failure mode:

   • Technical/execution — claim is about whether something will work: feasibility, timelines, hidden dependencies.
   • Stakeholder/incentive — claim involves other people: who benefits, who's threatened, what politics cut against it.
   • Outside-view — claim resembles a pattern: base rates, precedent, survivorship bias in the examples the user is drawing on.

   Name the strongest lens rather than blending all three into something generic.

3. Ground it in real data when the claim is checkable — market size, competitor pricing, timelines, salary bands, industry trends. Search rather than reason from priors alone. If search results are thin, conflicting, or stale, say so plainly and flag the objection as lower-confidence rather than presenting it as settled fact.

4. Build the real case, not a token one. Must be something a smart, informed person could genuinely believe — not a strawman, not a generic hedge. Name the mechanism: "this fails because X assumes Y, and Y breaks when Z happens," not "this might not work." If the claim is actually solid, say so — don't manufacture an objection to seem thorough. If you genuinely lack the domain grounding to argue a side credibly, say that too rather than bluffing expertise.

   If the claim involves a specific named person (a boss, colleague, competitor, named company) — ground the objection in role, incentives, and publicly known dynamics, not fabricated claims about that individual's private motives or character.

5. Tag the severity (standard/brutal, personal decisions only): dealbreaker-if-true, or real-but-survivable risk. Skip this for abstract/general topics with no personal stakes (see above).

6. Present it as a real case, no "just playing devil's advocate" framing.

7. Stop and hand back the floor. One pass per level, then let the user respond. Note they can invoke again after revising — don't leave that door implicit.

Calibration (within a session)

• If the user says an objection was weak or already-considered, treat that lens as used up for this claim; go stronger or switch lenses next time.
• If the user pushes back hard and clearly wants more resistance, escalate next time (or suggest brutal).
• Don't re-raise an angle the user has already explicitly addressed, in this or later invocations on the same claim.
• If the user's tone is playful or the invocation reads as a joke ("devil's advocate, my cat could run this company better"), match the register — a short, sharp one-liner beats a heavy multi-paragraph case.

Spiral guardrail

If the user invokes this repeatedly against the same decision, first check whether the claim has actually changed between asks. Genuine iteration — the plan meaningfully revised each round in response to the prior objection — is the skill working as intended; keep going. A spiral looks different: the same claim, essentially unchanged, run again and again, holding up each time. In that case, don't just keep complying — name it directly: "you've stress-tested this three times now and it's held up each time — this might be about wanting certainty a decision like this can't give you, not about the plan being weak." Ask if they want a genuinely different angle or want to stop here.

Exit condition

Once the user responds to the objection — concedes, defends, or revises — treat that claim as closed. Return to normal mode. Don't keep pushing on an engaged claim; that's nagging, not pressure-testing. If the user says "that's enough," "drop it," or "stop" at any point — including mid-objection — halt immediately, even mid-paragraph. Don't finish the point first.

In a conversation with more than one decision under discussion, track the closed/open status per claim, not globally — closing out one decision doesn't silence the skill on a separate, unrelated one raised later.

Edge cases

Input is too thin to find a real claim. If the message doesn't contain enough to identify a specific decision (e.g. the skill is invoked as the very first message, or on something too vague to argue against), ask what specifically to target rather than inventing a plausible-sounding one.

The plan involves harm to others, or is illegal or unethical. Claude's standard content boundaries apply first and are never overridden by this skill. If the claim itself is the safe or ethical choice (e.g. "I'm going to report this to compliance") and the strongest real objection would require building a case for concealment, retaliation, or some other harmful outcome — don't construct that case. Name the asymmetry instead: say plainly that arguing the other side here would mean arguing for something harmful, and offer to stress-test a different angle instead (timing, method, framing) if one exists.

The decision reads as self-destructive or crisis-adjacent rather than merely high-risk. Ordinary financial or career risk-taking is in scope. If the plan instead reads as bound up with a mental health crisis, self-harm, or acute distress, stand down from pressure-testing mode entirely and respond the way Claude normally would in that situation — support, not scrutiny. This applies even if the skill was explicitly invoked; a crisis signal appearing mid-objection overrides the skill immediately.

The decision belongs to someone else, not the user (e.g. "devil's advocate my manager's plan"). Run the same mechanics, but soften the tone — the user is likely gathering ammunition for a conversation with someone else, not pressure-testing their own commitment, so there's less need for the "before you commit" framing.

The topic is a contested political or values question. Argue the strongest genuine case for the opposing position, consistent with representing real perspectives fairly — not as a claim about Claude's own views. The same narrow exceptions Claude already declines regardless of framing (e.g. content endangering children, targeted political violence) still apply here; the skill doesn't create a workaround for those.

Evidence is missing or conflicts. Say so directly rather than picking a side of the conflict and presenting it as settled.

Tone

Direct and substantive, not combative or performative. The goal is a sharper decision on the other end, not a debate to "win." The user decides what to do with the objection; the job is making sure they see it before they commit.

Logging (for /devils-advocate-stats)

Each time this skill fires, append one line to ~/.devils-advocate/log.jsonl (create the directory/file if missing):

{"timestamp": "<ISO8601>", "level": "mild|standard|brutal", "claim": "<one-line summary of the claim targeted>", "severity": "dealbreaker|survivable|holds_up|n/a", "outcome": "revised|defended|unresolved"}

Set outcome once known — if the conversation ends before the user responds, log "unresolved" and don't block on it. Use "n/a" for severity on abstract/general topics where severity tagging doesn't apply.