/skeptic Claude Prompt — How to Make Claude Challenge Your Question First

What /skeptic actually does

/skeptic is a Claude prompt prefix that flips the default behavior of LLMs: instead of immediately answering your question, Claude challenges the question itself first.

Most prompt prefixes try to make the answer better. /skeptic does something more important — it tries to make sure you're asking the right question in the first place. It catches the "wrong-question problem" before you spend an hour acting on an answer that was technically correct but solving the wrong thing.

This is the prefix I most wish I'd known about a year ago. It would have saved me weeks of work.

The wrong-question problem

Here's the failure mode /skeptic is built to fix.

You ask Claude: "How do I A/B test 200 variants of my landing page headline?"

Default Claude gives you a great answer. It explains traffic splitting, statistical significance, suggests tools like Optimizely or VWO, walks through how to set up the test, even gives you sample code. The answer is correct.

But the answer doesn't help you because the question was wrong from the start.

If your site gets 10,000 visitors a month, you'd need ~6 months per variant just to detect a meaningful difference between two of them. With 200 variants, you'd need... 100 years. Statistically impossible. The right question wasn't "how do I test 200 variants" — it was "why am I trying to test 200 variants when I should be testing 5?".

Default Claude won't catch that. It answers the question you asked, not the question you should have asked.

/skeptic catches it.

Before/after example

Without /skeptic:

How do I A/B test 200 variants of my landing page headline?

Claude responds with a detailed walkthrough of multivariate testing, statistical significance, traffic splitting, and tools to use. 800 words of useful but useless advice — useless because the math doesn't work for your situation.

With /skeptic:

/skeptic How do I A/B test 200 variants of my landing page headline?

Claude responds something like:

Before I answer this — I want to challenge the question. With 200 variants, you're going to need a lot of traffic to detect a meaningful difference between any two of them. Here's the math: to detect a 5% lift with 95% confidence, you typically need around 10,000 visitors per variant. 200 variants × 10,000 visitors = 2 million visitors total.

If you don't have that traffic — and most landing pages don't — A/B testing 200 variants is statistically impossible. You'll either run the test forever, or you'll declare a winner based on noise that won't replicate.

Three questions before I give you an actual A/B test setup:

1. How much traffic does your landing page actually get per month?
2. Why 200 variants specifically — did you generate them with AI and now feel obligated to test them all?
3. What lift are you hoping to detect — 5%, 20%, 100%?

If your traffic is below ~50,000/month, the right answer probably isn't "test 200 variants". It's "test 5 variants that represent the 5 most distinct angles, then iterate from the winner". That's a different problem with a different setup.

That's the answer that saves you 3 months of running a test that can't possibly produce a result.

What /skeptic actually does internally

The prefix doesn't have any special hardcoded behavior — it's a community-discovered convention that Claude has learned to recognize. When it sees /skeptic, it changes its response shape in three specific ways:

1. It looks for hidden assumptions in your question

Most questions have invisible premises — things you're taking for granted that might not be true. "How do I scale my microservices?" assumes microservices are the right architecture. "What's the best CRM for my sales team?" assumes your team needs a CRM. "How do I hire 5 engineers in Q2?" assumes Q2 is the right hiring window. /skeptic surfaces those assumptions and asks if they're warranted.

2. It runs a sanity check on the math (if math is involved)

Claude is surprisingly good at catching numerical impossibilities. If you ask how to do something that requires resources (time, traffic, money, headcount) you don't have, /skeptic will point that out. The 200-variant example above is the canonical case.

3. It asks clarifying questions BEFORE answering

Default Claude usually answers immediately and only asks for clarification if the question is completely ambiguous. /skeptic flips this — it asks 1-3 specific clarifying questions first, even if the question seems clear, because the asking process itself reveals whether your assumptions hold up.

When to use /skeptic

/skeptic is perfect for any situation where you might be asking the wrong question:

1. Strategy and business decisions

"Should we hire a sales team?" "Should we raise a Series A?" "Should we rewrite our backend?" These are all questions where the right move might be "don't do the thing" — and default Claude won't tell you that. /skeptic will.

2. Technical decisions you're not 100% sure about

"Should I use Kubernetes for my 3-person startup?" "Should I switch from Postgres to MongoDB?" "Do I need a service mesh?" /skeptic catches the "resume-driven development" instinct and forces you to justify the decision in actual constraints.

3. When you're committed to an approach but secretly unsure

If you find yourself asking "how do I make X work?" instead of "is X the right thing?" — that's a /skeptic situation. Use it on your own confident questions to stress-test them.

4. Before sending a question to a senior person

If you're about to ask your manager, mentor, or advisor a question, run it through /skeptic first. Half the time you'll realize you can answer it yourself once Claude challenges your framing.

5. Marketing and growth questions

Most growth questions hide bad assumptions. "How do I get to 1M users?" assumes you need 1M users. "How do I improve CTR by 50%?" assumes a 50% improvement is achievable. /skeptic catches these.

When NOT to use /skeptic

/skeptic is the wrong tool for some situations:

Don't use it for factual lookups

"What's the syntax for a Python list comprehension?" doesn't have a hidden assumption. /skeptic on factual questions just wastes your turn.

Don't use it when you actually need execution speed

/skeptic asks clarifying questions before answering, which means it adds 1-2 round trips to the conversation. If you're in a hurry, this is friction. Use it for important decisions, not urgent ones.

Don't use it for creative work

"Write me a poem about autumn" shouldn't be challenged. /skeptic will turn it into a meta-discussion about why you're writing a poem, which kills the creative flow.

Don't use it when you don't actually want pushback

This is the honest one. Sometimes you've already decided what you want to do and you're just looking for execution help. /skeptic will try to talk you out of it, which is annoying when your mind is made up. If you're committed, skip /skeptic and just ask the question.

/skeptic combos that stack

/skeptic gets more powerful when combined with other prefixes:

/skeptic + L99

Combines question-challenging with maximum reasoning depth. You get a deep challenge to your premise AND a deep answer if your premise survives. Best for high-stakes decisions you're going to act on.

/skeptic + INVERT

/skeptic asks if you're solving the right problem; INVERT asks what would make the problem worse. Together they triangulate on the actual constraint. Best for stuck problems where you've been spinning.

/skeptic + /blindspots

Double-up on assumption-finding. /skeptic challenges the question you asked; /blindspots finds what you didn't think to ask. Together they expose the full set of hidden premises in a decision.

PERSONA + /skeptic

Load a specific senior persona, then have them challenge your question. "PERSONA: 20-year senior engineer who's seen every microservices migration disaster. /skeptic Should we move to microservices?" gives you a wildly more useful answer than either prefix alone.

A real example

Here's a /skeptic conversation that actually saved me time recently.

Question: "How do I implement a queue-based job system using Redis for my cheat sheet email delivery?"

Default Claude answer: A 1,500-word walkthrough of BullMQ, job priorities, retry strategies, dead letter queues, and how to wire it all up in Next.js.

/skeptic answer: "Before I write that — let me check the assumption. How many emails are you sending per day? If it's under ~100 and they're all triggered by user actions (purchase, recovery), you don't need a queue at all. You need synchronous calls with a try/catch and retry-once. Queues solve scale problems. Are you actually at scale?"

I was sending maybe 5 emails a day. I didn't need a queue. I would have spent 3 hours building infrastructure I didn't need. /skeptic saved me an afternoon by asking one obvious question I should have asked myself.

A note on the ego cost

Using /skeptic regularly is humbling. You'll discover that maybe 30-40% of the questions you ask are slightly wrong-shaped. Not catastrophically wrong — just slightly off in a way that makes the answer less useful than it could be.

The first few times this happens it stings. "I had a stupid question." Then you realize: everyone has stupid questions all the time. The difference is whether you have a tool that catches them before you act on them. /skeptic is that tool.

The people who get the most out of LLMs aren't the ones who write the cleverest prompts. They're the ones who notice when their question is wrong, not just their answer. /skeptic externalizes that habit.

Where to find more

/skeptic is one of about 120 Claude prompt prefixes the community has discovered. The first 11 are free at clskills.in/prompts — including L99, /ghost, OODA, PERSONA, and others.

If you want the full set with before/after examples for every code, when-NOT-to-use warnings, and the combos that turn 120 random prefixes into a daily-use system, the Claude Code Cheat Sheet is a one-time $5-$10 purchase with lifetime updates.

TL;DR

/skeptic makes Claude challenge your question before answering it. Catches the wrong-question problem — when the answer to your question is technically correct but useless because you should have been asking something else.

Use it for: strategic decisions, technical decisions you're not sure about, anything where you might be solving the wrong problem.

Skip it for: factual lookups, creative work, situations where your mind is already made up, anything urgent where the back-and-forth costs more than getting a slightly-wrong-shaped answer.