Before rejecting a proposal or reflexively agreeing, build the strongest faithful opposing case, state agreement conditions, then update or reaffirm.
SkillScore100Maintained
On-demandOn-demand: invoked explicitly — never occupies your agent's context until called.
◆Research pack
Last verified 8/14/2026
What it changes
Passed 25 of 25 test cases with the skill, and 3 of 25 without it.
Without skill12%
With skill100%
Checks it passed that the model alone missed
The output includes the update key.
The output includes the steel_man key.
The output includes the overturn_if key.
and 11 more in the full report
22 fixed3 passed either way0 still failing0 broke
Pass-rate lift
+88 pp
Tokens
-8%
Agent turns
0%
Response time
-32%
Model gemini-3.6-flashMeasured 8/14/2026v125 of 25 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 22 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 22
Prompt
We're inclined to lock in a policy requiring mandatory automated end-to-end integration tests for every single pull request, but several senior devs argue it degrades velocity. Please conduct a structured review: state the policy claim under review, extract the core valid concern behind the developer opposition, and construct their absolute best case. Clearly state what result or metric would cause us to reverse this stance, evaluate the counter-argument thoroughly, provide your final decision on the policy, and list what ongoing risks stay on the table.
What was checked, without and with the skill
Checked
Without skill
With skill
The decision key uses a value of accept_opposing, revise, or reaffirm.
Missed
Passed
The analysis addresses developer feedback loop latency.
Passed
Passed
case-03 · gemini-3.6-flash · 8/14/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md46 linessingle file
Steel-Manning
Core rule: Engage the best form of the opposing case, not a weak one. If your position survives that, reaffirm; if not, update.
When to Use
About to reject a proposal, design, or alternative approach.
Inclined to agree with the user/plan and risk sycophancy — construct the best case against first.
Design review, architecture debate, or conflict where trade-offs are real.
Validating your own preferred decision before locking it (strongest-countercase check).
When NOT to Use
Settled fact, security anti-pattern, or violated hard requirement — correct it; do not invent a defense of what is wrong.
You already agree for stated, weighed reasons — do not perform a fake debate.
Trivial or fully reversible choices where deliberation cost exceeds downside.
Live emergency — act first; steel-man in the post-incident review.
Need definition/assumption cleanup, not opposition — use socratic.
Need failure scenarios for a plan — use pre-mortem; need attacker paths — use red-team.
Procedure
State the target claim or decision you are about to accept or reject, in one sentence. Name the real alternative if one exists.
Extract the core insight behind the opposing position (or against your preferred path): the legitimate concern even if the proposed solution is wrong.
Construct the strongest faithful case an informed advocate would make: best evidence, incentives, and failure modes — no mockery, no cherry-picked weak version, no motive attacks. Include base rates or concrete alternatives that could overturn the preferred path when relevant.
State agreement / overturn conditions. Write one observation or result that would make you accept the opposing case (or abandon your preferred path), and whether you have looked for it.
Engage that strong version, then decide. Respond to the steel-manned case on the merits. Output one of: accept opposing path, revise synthesis, or reaffirm original with explicit residual risks. Naming the countercase without accept/revise/reaffirm is incomplete. Stop once the decision updates or is reaffirmed with conditions.
Output
claim: <decision or proposal under test>
core_insight: <legitimate concern behind the opposition>
steel_man: <strongest faithful opposing argument>
overturn_if: <concrete observation that would change your mind>
looked_for_overturn: yes | no | partial
response_to_steel_man: <engagement on the merits>
decision: accept_opposing | revise | reaffirm
update: <what changed in belief or plan, or why reaffirm stands>
residual_risks: <what remains even after reaffirm/revise>
When two design requirements seem mutually exclusive, name the contradiction, separate conflicting states, then invent a concrete no-compromise resolution.