From 3-surgeons
HARD-GATE — force adversarial counter-arguments to ensure both sides of a decision are examined
npx claudepluginhub supportersimulator/3-surgeons --plugin 3-surgeonsThis skill is limited to using the following tools:
**An opinion is NOT valid until you can effectively argue BOTH sides.**
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
An opinion is NOT valid until you can effectively argue BOTH sides.
This is not debate for debate's sake. It is the core epistemological discipline: if you cannot steelman the opposition, you have not understood the problem deeply enough to decide. Confirmation bias is the failure mode this protocol exists to prevent.
Do NOT finalize any architectural decision until counter-position has been run. If you cannot construct a strong argument against your preferred position, your confidence is not earned.| Signal | Why |
|---|---|
| Any architectural decision | Architectural choices are expensive to reverse |
| High confidence + low evidence | Confidence without evidence = confabulation |
| Single surgeon dominates consensus | Groupthink risk — the dissenting view needs construction |
| Sentinel risk >= high | High-risk changes deserve adversarial scrutiny |
| "Obviously" or "clearly" in reasoning | These words often mask unexamined assumptions |
You MUST create a TodoWrite task for each step:
What is being asserted? Write it as a clear, falsifiable statement.
Good: "We should use Redis sorted sets for the priority queue because they provide O(log N) insertion with built-in ordering."
Bad: "Redis is the right choice." (Too vague to counter — what aspect? Compared to what?)
Construct the strongest possible argument AGAINST the claim. This is not a strawman — it is the best case the other side could make.
Rules:
Check the counter-argument against actual code, evidence, and data. This is where theory meets reality.
| Evidence Grade | Standard | Action |
|---|---|---|
| Empirical | Tested against running code/system | Trust — this is ground truth |
| Documented | Referenced in docs, specs, prior decisions | Trust — verified by prior work |
| Analogical | Pattern from similar systems/contexts | Consider — useful but not conclusive |
| Theoretical | Reasoning from principles without direct evidence | Investigate further before deciding |
| Anecdotal | Single observation or claim without verification | Do NOT decide based on this alone |
Counter-position decisions MUST be backed by Empirical or Documented evidence. Theoretical/Anecdotal evidence triggers additional investigation.
Only after testing both sides, form a position:
Ask with code-specific framing:
You are part of a SOFTWARE DEVELOPMENT protocol called '3-surgeons'.
You are the local LLM (Qwen3-4B). We write CODE, not perform medical surgery.
CLAIM: [the assertion being tested]
COUNTER-ARGUMENT: [the steelmanned opposition]
YOUR ROLE: Classify which side has stronger pattern support based on the
code context provided. Look for: similar patterns in the codebase,
precedent from prior decisions, technical constraints that favor one side.
CODE CONTEXT: [relevant code snippets]
Why domain anchoring: Without explicit code-context framing, Qwen3-4B confabulates into medical neurology. Confirmed empirically: 3/3 false positives without anchoring, 7/7 actionable responses with anchoring.
Ask to cross-examine the evidence for both positions:
Cross-examine these two positions for a SOFTWARE DEVELOPMENT decision:
POSITION A: [the claim]
EVIDENCE A: [supporting evidence with grades]
POSITION B: [the counter-argument]
EVIDENCE B: [supporting evidence with grades]
Check for: logical consistency, cognitive biases (confirmation, anchoring,
availability), confidence calibration, and whether evidence grades are
accurately assigned.
The cardiologist's strengths to exploit here: