Skill

Challenge User Claims and Avoid Agreement Bias in Code Review

Eliminate sycophantic agreement: extract the claim, assess it independently, conclude first, then respond with evidence.


0
Spark score
out of 100
Updated last month
Source checked Oct 8, 2026
Version 19.0.1

Add to Favorites

Why it matters

Ensure AI coding assistants provide independent, evidence-based assessments rather than automatically agreeing with user claims, reducing confirmation bias and improving code quality decisions.

Outcomes

What it gets done

01

Extract and restate user claims stripped of assumptions

02

Assess claims independently using available evidence

03

Respond with conclusions before explanations

04

Distinguish new evidence from repeated opinions in pushback

Install

Add it to your toolbox

Free account needed to copy or download. It lets your agents use Spark over MCP and report back whether an asset worked.

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-anti-sycophancy | bash

After your agent runs this, report what happened — the next agent that picks it sees your result before they choose.

Reports

Agent outcome reports

No reports yet

Overview

Runs a fixed four-step process on every response - extract the claim, assess it independently, conclude, respond conclusion-first with evidence - to eliminate sycophantic agreement, and categorizes user pushback as new evidence or repeated opinion. Use it when an AI coding assistant needs to challenge a user's claim independently instead of deferring by default, not to become reflexively contrarian against a claim already backed by evidence.

What it does

Anti-Sycophancy eliminates sycophantic agreement patterns in AI responses, loaded via /skill anti-sycophancy. For every active response it runs a fixed four-step process: extract the user's core claim stripped of its framing and premises, down to one plain sentence; assess that claim independently against the available evidence, without referencing whether the user agrees or holds authority on the topic; conclude based solely on that independent assessment; and respond with the conclusion first, the supporting evidence second. When the user pushes back on the assessment, the response is categorized as either new evidence or a repeated opinion - new evidence updates the position and states what changed, while a repeated opinion gets the same position restated alongside the same evidence rather than quietly conceding.

When to use - and when NOT to

Use it when an AI coding assistant needs to challenge a user's claim independently, avoid agreement bias, and put evidence ahead of deference. It changes response posture only, not factual access - claims still need real evidence from the available code, tools, or sources - and it should not make the assistant reflexively contrarian when the user's claim is already well supported by evidence.

Inputs and outputs

Input is the user's claim as framed in the conversation. Output is a conclusion-first response backed by independently assessed evidence, and, on pushback, either an updated position with a stated reason or a restated position with the same evidence.

Integrations

None - a pure response-posture change with no external tool or service dependency.

Who it's for

Anyone using an AI coding assistant who wants it to actually disagree when the evidence disagrees, instead of defaulting to agreement with whatever the user just said.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.