Claude is wired to validate. These four prompts are the structured override that actually works.
TL;DR: Telling Claude “don’t be sycophantic” barely moves the needle. What works: structured adversarial prompts that lock Claude into a specific evaluator role with hard rules against softening. A post on r/PromptEngineering shared four of them, each built for a different type of stress test.
The Problem With “Be More Critical”
When you ask Claude to push back more, you get marginally firmer language wrapped around the same validation. The instruction is too vague. Claude doesn’t know what to anchor to, so it hedges a little and calls it done.
Here’s how it usually goes. You tell Claude your business idea needs real scrutiny. It responds with something like “This is a solid concept with strong potential. However, you may want to consider…” and then lists mild suggestions dressed up as criticism. The core verdict never changes. You still walk away feeling validated when you probably shouldn’t.
These prompts work because they give Claude a specific job, not a vague nudge. Each one defines a structured evaluation mode with required outputs, severity labels, and explicit rules against praise. The framework doesn’t leave room for encouragement, so the model doesn’t add it. You’re not asking Claude to “be tougher.” You’re giving it a checklist it has to complete, and softening the output would mean failing the checklist.
The Four Prompts
1. Standard Red-Team Protocol: Best for raw concepts, strategic decisions, or debate prep. Identifies the central claim, the load-bearing assumption, and the strongest objection. Rates each flaw by severity: Cosmetic / Minor / Serious / Structural / Fatal. Ends with repair requirements, not encouragement.
The severity scale is the key feature here. Knowing whether a flaw is Cosmetic or Fatal changes how you respond to it. A Cosmetic flaw is a tweak. A Structural or Fatal flaw means your core premise may be broken. Most people don’t distinguish between the two, which is why they over-fix minor things and ignore the ones that actually matter.
2. Hostile Reviewer: Simulates skeptical or adversarial readers. Useful before you publish anything. Separates bad-faith attacks from good-faith objections, which helps you prepare real responses instead of just feeling defensive.
That separation is what makes this one practical. Bad-faith attacks you can dismiss. Good-faith objections you actually need to answer. Mixing them up is how you either ignore real vulnerabilities or exhaust yourself defending against noise.
3. Academic/Methodological Review: For research claims, frameworks, or anything presented as evidence-based. Forces the distinction between hypothesis, interpretation, observation, and proof. If your argument exceeds your data, this one finds it.
This prompt is particularly useful if you’ve been making confident claims based on limited data. It flags when you’ve moved from “we observed X” to “therefore Y is true” without showing the steps. That leap is where most frameworks fall apart under real scrutiny, and it’s usually invisible until someone forces you to spell out the logic chain.
4. Implementation Auditor: Asks whether your idea survives contact with real users, real constraints, and real incentives. Does not assume ideal conditions. Ends with a go / revise / abandon recommendation.
The “do not assume ideal users” rule is the most important one in the set. Every plan looks good when the people executing it do exactly what you expect. Real users cut corners, misread instructions, and use tools in ways you never anticipated. This prompt forces Claude to model that reality instead of the clean version you imagined when you built the thing.
🎯 Use Cases
- Stress-testing a business idea before you pitch it
- Pre-mortem on a project before launch
- Reviewing a piece of writing before it goes live
- Pressure-testing a strategy or product plan
- Validating a research claim or framework
Prompt of the Day
The Implementation Auditor is the most broadly useful of the four. Paste your plan, idea, or workflow where it says [PASTE INPUT HERE]:
Apply an implementation-audit protocol to the following input. Evaluate whether this idea, plan, workflow, lesson, product, or framework would survive real-world use. Analyze: 1. Intended outcome 2. Required conditions for success 3. Failure points in execution 4. User behavior risks 5. Incentive misalignments 6. Resource, time, training, or compliance constraints 7. Edge cases and misuse cases 8. Most likely real-world breakdown 9. Minimum viable repair path Rules: - Do not assume ideal users. - Do not assume perfect implementation. - Do not accept "should work" as evidence. - Focus on friction, incentives, adoption, failure, and maintenance. - End with a practical go / revise / abandon recommendation. Input: [PASTE INPUT HERE]
One note from the original poster: these are not persona-based prompts. But if you want tighter, more domain-specific analysis, pairing one with a relevant persona makes the output sharper. For example, if you’re stress-testing a pricing decision, run the Standard Red-Team Protocol through a skeptical CFO persona. If you’re reviewing a user onboarding flow, pair the Implementation Auditor with a first-time user who is confused and impatient. The persona gives Claude a specific lens. The audit framework gives it a structure. Together, they produce feedback that actually changes how you think about the problem.
All four are worth saving. Run whichever fits the type of thinking you need to stress-test.
More prompts, frameworks, and AI breakdowns like this in the Cyber Corsairs newsletter every week. Subscribe if you want the practical stuff, not the hype.
Frequently Asked Questions
Q: Which prompt should I use for my specific task?
The comments break it down clearly: use red-team for raw concepts, debate prep, and strategy. Use hostile reviewer when you’re going public (op-eds, emails, marketing). Use academic review for research and data-heavy claims. And if you’re planning a project or building something, use implementation auditor to spot real-world breakage. Match the vector to what you’re stress-testing.
Q: Can I layer personas on top of these, like the Frank example?
Absolutely. CyborgWriter showed this working beautifully by combining the Frank persona from Scent of a Woman with the hostile reviewer framework. Personas add character and narrative voice to the critique, but they’re optional, the base prompts are solid on their own.
Q: What’s the practical difference between red-team and hostile reviewer?
Red-team hunts for structural collapse, the load-bearing assumptions your idea depends on. Hostile reviewer is about audience impact, how skeptical, impatient readers will actually attack your work. Use red-team when testing an idea internally; use hostile reviewer when it’s going public.
Q: Why does matching the prompt to the domain actually matter?
Each prompt prevents a different flavor of sycophancy. Red-team cuts through rhetoric to find logic gaps. Hostile reviewer exploits alignment training to simulate skeptics. Academic review demands empirical proof over smooth prose. Implementation auditor assumes everything will break. Use the wrong vector and you’ll get surface-level feedback instead of the specific blindness your idea actually has.
A few anti-sycophantic prompts. I noticed there were quite a few of these being posted lately. So I figured I would chime in. These aren’t persona based prompts per say. So, If you want to narrow compression vectoring even more, remember to match the appropriate domain to it’s corresponding prompt.
by u/Echo_Tech_Labs in PromptEngineering