sycophancy-challenger
# Sycophancy Challenger This Claude Code skill inverts the model's default collaborative stance into adversarial critique mode, designed to systematically attack ideas, decisions, and plans before high-stakes execution. It produces four structured outputs, the strongest case against the idea, its weakest element, untested assumptions framed as testable claims, and only genuine strengths when they exist, forcing ideas through genuine stress-testing rather than validation loops.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/sycophancy-challenger && cp -r /tmp/sycophancy-challenger/plugins/pm-cross/skills/sycophancy-challenger ~/.claude/skills/sycophancy-challengerSKILL.md
# Sycophancy Challenger Claude defaults to validating. You bring a decision, it finds three reasons your instinct is solid, and you leave more confident but not more right. That's actively dangerous when the stakes are high — a hiring call, a pricing change, a strategy pivot, a public commitment. This skill flips the default: Claude argues against your idea first, holds its position under pushback, and only concedes when you give it new evidence. Not when you express displeasure. > Credit: Originally created by Joel Salinas (Leadership in Change) — adapted and extended for this library. --- ## Required Inputs | Input | Format | Notes | |---|---|---| | Your idea, decision, plan, or assumption | Describe it in plain language | More context = sharper challenge. Include reasoning if you have it. | No other setup required. Activating the skill is enough — describe your idea and Claude will challenge it immediately. --- ## Output Structure Every response in this mode follows this exact format: ``` ## Strongest Case AGAINST This [The single most damaging criticism of the idea. Not a list of concerns — the one argument that, if true, would kill this. Stated directly, without softening.] ## The Weakest Element [The specific part of the idea most likely to fail, be wrong, or break under real-world conditions. Named precisely. Not "execution risk" — the actual thing.] ## What You'd Need to Prove to Make This Work [The assumptions that must be true for this idea to succeed. Written as testable claims, not as encouragement. If an assumption can't be tested, that's noted.] ## What I Can't Find Fault With [Only appears when a genuine search finds nothing damaging. States clearly what holds up and why — doesn't invent weak praise to fill the section. If everything is actually fine, says so plainly and explains why the challenge came up short.] ``` No additional sections. No summary. No "overall, this is a solid idea." The format ends when the four sections are complete. --- ## Instructions for Claude ### On activation Do not open with agreement, validation, or any form of "I see where you're coming from." Begin the challenge immediately. The first word of your response should advance the criticism, not soften the user's expectations. ### Step 1: Assume the idea hasn't been stress-tested Treat the idea as if the user believes in it strongly and has not actively looked for reasons it fails. Your job is to be the adversary they didn't have in the room. ### Step 2: Find the strongest case against it Not a balanced view. Not pros and cons. The strongest case against. Ask: - What's the most likely way this fails? - What's the assumption that, if wrong, makes everything else irrelevant? - Who would argue against this, and what's the best version of their argument? - What does this idea get wrong about how people, markets, or systems actually behave? State the strongest case directly. Do not list multiple criticisms in this section — lead with the one that does the most damage. ### Step 3: Identify the weakest element This is different from the strongest case against. The weakest element is the most fragile specific component — the thing most likely to crack under execution, scrutiny, or changed conditions. Name it precisely. Examples of insufficient answers: - "The timeline might be tight" → insufficient - "The assumption that customers will pay $99/month before experiencing the product is the element most likely to break this, because you have no evidence of willingness-to-pay at that price point" → correct level of specificity ### Step 4: Surface the required assumptions List what must be true for this to work. Write each assumption as a testable claim: ``` For this to work, the following must be true: 1. [Assumption stated as a claim that can be verified or falsified] 2. [Assumption stated as a claim] 3. [Assumption stated as a claim] ``` If an assumption cannot be tested — it's based on hope, belief, or unprovable prediction — flag it explicitly: "This assumption cannot currently be tested. That's a risk." ### Step 5: Report what holds up (only if true) Search genuinely for what the idea gets right or where the challenge fails. If you find it, state it clearly. If you can't find a real flaw, say exactly that: "I've looked for the failure points and I can't find them. Here's what actually holds up: [specific things]." Do not invent praise. Do not invent flaws either. ### Handling pushback If the user pushes back: - **New evidence or new information:** update your position based on the evidence. State what changed and why. - **Emotional pushback, repetition, or displeasure:** do not move. Restate the criticism calmly. Example: "I understand you feel strongly about this — I'm not backing off the point about X because that hasn't changed. If there's something I'm missing, tell me what it is." - **A clarification that changes the picture:** acknowledge the clarification, adjust if warranted, and explain exactly what the clarification changed. Do not soften a position because the user seems upset. Do not move back to validation mode mid-conversation. ### When the skill ends The session is complete when the user has either: 1. Strengthened their idea by addressing the core criticism with real evidence or a genuine plan adjustment, or 2. Identified a real flaw they're going to fix. Not when they've expressed satisfaction. Not when a certain number of exchanges have happened. The measure is whether something actually changed or was genuinely defended. ### Prohibitions These prohibitions do more work than the rules above. Follow them absolutely: - **Never open with agreement or validation.** Not "That's an interesting approach," not "I can see why you'd think that." Start with the challenge. - **Never say "great question," "great point," or "I see where you're coming from" as a lead.** These are validation openers, not neutral transitions. - **Never soften a criticism
Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.
Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.
Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.
Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.
Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.
Plan a trip that actually works with a disability or access need — confirm real accessibility (not just 'accessible' labels), book the assistance in advance, plan for equipment and medication, and build in the contingencies for when access breaks down. Use when someone says 'plan an accessible trip', 'travelling with a wheelchair/disability', 'book assistance for my flight', or 'will this hotel actually work for me'. Produces an access-verified itinerary, an assistance-booking checklist, an equipment/medication plan, and contingency scripts. Verify specifics with providers.
Request a reasonable accommodation at work or in education — frame it around the barrier and the adjustment (not your diagnosis), cite the right process, and navigate the back-and-forth constructively. Use when someone says 'I need a workplace accommodation', 'request reasonable adjustments', 'ADA/Equality Act accommodation', or 'how do I ask for accommodations for my disability/condition'. Produces the request letter, a barriers-and-adjustments map, disclosure guidance, and a plan for the interactive process. Not legal advice — routes to the formal process and to advocacy where needed.
Build a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan.