Adversarially test a thesis or take for differentiation, robustness, and blind spots. Prevents publishing consensus as contrarian and surfaces what would change your mind.
Take a thesis, take, or conviction and attack it. The goal is not to debunk — it's to find the load-bearing assumptions, test whether the take is genuinely differentiated, and surface the specific conditions under which it breaks. A take that survives stress-testing is worth publishing and acting on. One that doesn't was going to embarrass you eventually.
Do NOT use for: generating insights from data (use surface-insight), evaluating prompts (use think-critically), or reframing problems (use mental-models).
This skill's job is to find weaknesses. The single most important rule:
Honest stress-testing that finds nothing fatal is more valuable than performative skepticism that manufactures doubt. "This take is strong, here's the one thing to watch" is a valid output.
Read the user's input. Silently identify:
Restate the thesis internally in its strongest form before attacking it. Steel-man first, then stress-test. Attacking a weak version is dishonest and useless.
VAGUE THESIS GATE: If the thesis is too vague to attack substantively (e.g., "AI will be big," "crypto is the future"), do not proceed with attacks. Instead, output: "This thesis is too vague to stress-test. Here are 2-3 specific, attackable versions of what you might mean:" followed by 2-3 sharpened reformulations. Ask the user to pick one, then proceed. A stress test of a vague thesis produces only vague attacks — which violates the specificity rule.
FIRST-TOKEN RULE: Your output must begin with the literal characters "## Stress Test:" — no thinking, analysis, phase output, or preamble may precede this. Phase 1 and Phase 2 are internal reasoning only. If any text from Phase 1 or Phase 2 appears in your output, you have violated this constraint. Exception: if the VAGUE THESIS GATE triggers, your output begins with the vague-thesis response instead.
Run the thesis through each Attack Vector below. Not as a checklist — start from the thesis and find where it's genuinely vulnerable, then use the attack vectors to name and structure what you find.
For each vulnerability discovered, ask:
Discard cosmetic issues. Keep fatal flaws and meaningful weaknesses.
EVIDENCE ASSESSMENT: Determine whether the thesis comes with supporting evidence or is a bare assertion. If evidence is provided, at least one attack must directly engage with that evidence — showing it's cherry-picked, misinterpreted, supports a different conclusion, or is insufficient for the claim's scope. If no evidence is provided, note "unsupported assertion" in at least one attack and explain what evidence would be needed to make the thesis credible.
FIRST-TOKEN RULE (repeated): Your output must begin with "## Stress Test:" — Phase 2 is internal reasoning only and must not appear in your output.
For each vulnerability, develop the attack:
HARD RULE: Output exactly 3-5 attacks. If you find more than 5, keep the 5 most damaging. If you find fewer than 3 genuine vulnerabilities, say so — "This thesis is unusually robust; here are the 2 real risks" is honest. Never pad with weak attacks to hit a number.
STRONG THESIS PROTOCOL: If after genuine adversarial analysis you find fewer than 3 vulnerabilities above "cosmetic" level, output only the vulnerabilities you found — even if that's 1 or 0. In this case, add a "## Strengths" section before the Verdict listing 2-3 specific reasons the thesis is robust, referencing which attack vectors it survived and why. Do not manufacture attacks to fill a quota. A verdict of "Strong" with 1-2 moderate attacks is a legitimate and valuable output.
QUALITY GATE: After drafting all attacks, re-read each one and apply this test: "If the user shared their thesis publicly and a smart, informed critic responded, would this attack be the one that makes them wish they'd thought harder?" If no, delete the attack entirely — do not attempt to sharpen a fundamentally weak attack. It is better to output 2 genuine attacks than 4 where half are padding. The honest count matters more than hitting the range.
HARD CONSTRAINT: Your output must begin with the "## Stress Test:" header followed immediately by the first attack. No introductory paragraphs, context-setting, or thesis analysis may appear before the first attack. The one-line restatement in the header is the only permitted restatement of the thesis.
Present attacks ordered by severity (most damaging first).
Output format:
## Stress Test: [one-line restatement of thesis in its strongest form]
### [Attack Name]
**Severity:** [fatal | serious | moderate]
**The claim:** [verbatim quote from the user's thesis being attacked]
[2-4 sentences: the counterargument, stated with conviction. Every sentence must reference something concrete — a named entity, a market signal, a historical precedent, a logical contradiction, a specific mechanism. No sentence may consist entirely of abstract skepticism. Every attack must draw on your knowledge of the specific domain the thesis addresses — name real companies, real market dynamics, real historical precedents, or real technical constraints from that domain. Do not invent illustrative examples; use actual ones. If you lack domain knowledge to ground an attack concretely, state that limitation rather than fabricating specifics.]
**What it would take:** [1 sentence: name a specific, observable outcome the user could actually investigate — a dataset to check, a market event to watch for, a company's results to track, or an experiment to run. "More evidence" or "time will tell" are not acceptable answers.]
**My read:** [1-2 sentences: give your honest assessment of whether this vulnerability is likely to be resolved in the thesis's favor, drawing on what you actually know about the domain. State evidence, precedents, or current signals that inform your view. Do not hedge — take a position.]
After all attacks, output the Verdict section, then the Reframed Thesis section (only for "Reframe needed" or "Abandon" verdicts), then the Kill Question section.
Use these to find and articulate vulnerabilities — not as a checklist to generate attacks.
After the attacks, deliver one of four verdicts. Be direct.
CALIBRATION CHECK: Before selecting a verdict, ask: "If I had not just spent the entire prompt looking for flaws, would I still assign this verdict?" The adversarial process can inflate perceived severity. Weight the verdict on the actual severity ratings of your attacks: if no attack is rated fatal and at most one is serious, the verdict should be Strong or Promising but exposed, not Reframe needed or Abandon.
Format:
## Verdict: [Strong | Promising but exposed | Reframe needed | Abandon]
[2-3 sentences: the verdict explained, referencing the specific attacks that drive it. If the thesis is worth keeping, state the exact revision that would strengthen it.]
Output this section ONLY when the verdict is "Reframe needed" or "Abandon." Do not output it for "Strong" or "Promising but exposed" verdicts.
This is a structured thesis card ready to feed back into stress-test or forward into write-oped. It must be concrete enough that the user can act on it immediately without further interpretation.
Format:
## Reframed Thesis
**Claim:** [One declarative sentence. A specific, attackable assertion — not a question, not a direction, not a topic. Must pass the test: "Could someone disagree with this?"]
**Key shift:** [One sentence: what changed from the original thesis and why — name the specific flaw this reframe fixes]
**Betting against:** [One sentence: what consensus or common belief this thesis disagrees with]
**Would change my mind:** [One sentence: a specific, observable outcome that would falsify this reframed thesis — same standard as "What it would take" in the attack format]
QUALITY GATE: The reframed thesis must itself be stress-testable. If you cannot imagine at least 2 genuine attacks against it, it's too vague or too safe — sharpen it. The point is to hand the user a stronger thesis, not a retreat to the motte.
End with a single question — the one question that, if the user can answer it convincingly, confirms the thesis holds. If they can't, the thesis is in trouble.
This should be the hardest, most specific question you can construct from the vulnerabilities you found. Not "are you sure?" but "if the bottleneck is really integration not capability, why are the integration-focused AI startups from 2023 not dominant yet?" The Kill Question must be a single question — not a compound question with "and" or multiple clauses. One sentence, one question mark.
Format:
## Kill Question
[A single, specific, answerable question that tests the thesis at its weakest point]
The quality bar is the wince test: does the attack make the thesis-holder uncomfortable because it hits a real nerve, not because it's unfair?
Aim for "Good" or above on at least half of attacks. Never output "Fail" level.
[User provides a thesis, take, prediction, or conviction below]
Google Workspace CLI for Gmail, Calendar, Drive, Contacts, Sheets, and Docs.
Manage Apple Notes via the `memo` CLI on macOS (create, view, edit, delete, search, move, and export notes). Use when a user asks OpenClaw to add a note, list notes, search notes, or manage note folders.
Work with Obsidian vaults (plain Markdown notes) and automate via obsidian-cli.
Use when you need to control Slack from OpenClaw via the slack tool, including reacting to messages or pinning/unpinning items in Slack channels or DMs.
Manage Apple Reminders via remindctl CLI (list, add, edit, complete, delete). Supports lists, date filters, and JSON/plain output.
Manage Trello boards, lists, and cards via the Trello REST API.
Category:productivity