agentleFS
samsational-codesamsational-code/business-skills/red-team-premortem/SKILL.md

red-team-premortem

Skill0 starsChanged 2 months agoMITView on GitHub

Run an adversarial pre-mortem on any thesis, plan, strategy, or decision: steelman the opposite case, rank the argument's assumptions by fragility, identify what evidence would falsify each one, define kill criteria the user pre-commits to, and surface the cognitive traps in the write-up itself. For anyone about to commit resources to a bet — a product launch, a market entry, a pricing change, a reorg, a hire, a vendor selection, a fundraising plan, a research hypothesis, a policy proposal, a campaign, an acquisition, an investment. Trigger on phrases like "red-team this," "poke holes in this," "what's the case against I'm missing," "steelman the other side," "pre-mortem this plan," "argue against me," "stress-test this memo," "why am I wrong," "assume this failed — why," or when a user pastes a proposal, strategy doc, business case, or thesis and wants it attacked rather than summarized. Do NOT use for a neutral first look at a company — use the company-first-pass skill. Do NOT use for evaluating a vendor, partner, or counterparty — use the counterparty-diligence skill. Do NOT use to write the decision memo itself — use the decision-memo-drafter skill, then bring the draft here to be attacked.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Steelman, not strawman: If the opposing case isn't one a smart opponent would actually run, rewrite it.

    line 106
  2. Distinctive:

    Brutal ≠ contrarian theater: If the thesis is genuinely strong somewhere, say so — credibility of the attack depends on conceding the …

    line 108

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Red Team Pre-Mortem

Take a thesis, plan, or decision the user has written and attack it the way the best person on the other side would: steelman the opposing case, rank every load-bearing assumption by fragility, specify what evidence would falsify each one, define kill criteria the user pre-commits to, and name the cognitive traps visible in the write-up itself. Brutal on the argument, constructive in the output.

Why this skill exists

Nobody on a team is truly incentivized to kill a colleague's idea — people are polite, the author is anchored, and devil's-advocate sessions reliably collapse into the advocate going easy. Meanwhile the actual opposition — the competitor, the skeptical customer, the board member who will vote no, the market that won't cooperate — is smart, motivated, and not in the room. The fix is structural, not motivational: a pre-mortem run by an adversary with no stake in the idea surviving, forced through a fixed protocol (steelman → fragility ranking → falsifiability → kill criteria → bias scan) so flattery has nowhere to hide. The output makes the plan stronger or kills it early — both outcomes pay.

Inputs

Required:

  • The thesis: a write-up, memo, proposal, business case, strategy doc, pitch, or even a few structured paragraphs. The direction must be clear (do it / don't do it, build / buy, launch / hold, invest / pass, for / against). If direction is ambiguous, ask once. A bare topic with no argument isn't red-teamable — ask for the actual reasoning, since attacking a thesis the user didn't write helps no one.

Optional:

  • Commitment context: how much is at stake (budget, headcount, time, capital), the horizon, what has already been decided, what the user believes the audience already assumes
  • What the user thinks the strongest counterargument is — the red team should beat it
  • Supporting materials the thesis relies on (model, customer interview notes, research, data, filings, prior post-mortems)
  • Permission to use your AI's web search to check claims against public sources (recommended; otherwise the red team attacks logic and structure only and says so)

Missing-input behavior: Proceed with the write-up alone. Label every assumption the red team has to make ("Assuming a 12–18 month horizon since none was stated"). If the user's position is against something (a plan to cancel, a case to pass), flip the protocol: steelman the case for it.

How it works

  1. Restate the thesis fairly. Two or three sentences the user would endorse, plus the implicit claims the write-up depends on but never states — those are usually where it dies.
  2. Steelman the other side. Write the strongest opposing case as if made by the sharpest, most motivated opponent — the competitor's head of strategy, the customer who churns, the skeptical board member, the analyst on the other side of the trade: their best 3–5 arguments, their strongest evidence (sourced where web access permits, labeled as unverified-logic otherwise), and their answer to the user's best point. No strawmen — the test is whether the user finds the opposing case uncomfortably persuasive.
  3. Extract and rank assumptions by fragility. List every assumption the thesis needs (stated and unstated). Score each: how load-bearing (does the thesis survive without it?) × how supported (verified fact / reasonable inference / hope). The fragile quadrant — load-bearing and weakly supported — gets named explicitly.
  4. Falsifiability pass. For each major assumption: is it falsifiable at all, what specific evidence would falsify it, when and where would that evidence show up (a pilot metric, a conversion rate, a churn number, a hiring funnel stat, a regulatory decision, a competitor launch, a quarterly KPI, a survey result)? Assumptions nothing could ever disprove are flagged as faith, not analysis.
  5. Define kill criteria. Convert the most fragile assumptions into 3–5 pre-committed, observable exit conditions: "If [observable event/threshold] by [timeframe], the thesis is broken regardless of how invested we are." Distinguish thesis-kill (the reasoning failed) from a bad stretch (a number moved for reasons that don't touch the logic) — the criteria must be about evidence, not about a single lagging outcome metric or a price.
  6. Scan the write-up for cognitive traps, quoting the offending language: confirmation bias (only confirming sources cited), anchoring (targets anchored to a past number, an original budget, a benchmark, or a prior valuation), narrative over base rates ("this time is different" without addressing why the base rate for this kind of plan doesn't apply), sunk-cost residue ("we've already invested two years in this"), authority transfer ("[big-name company / famous expert / well-known investor] is doing it"), recency extrapolation (last quarter's trend projected indefinitely), planning fallacy (timelines with no slack), survivorship (only the successes of similar bets cited), and missing disconfirming-evidence search. Only flag traps actually present.
  7. Close constructively: what would make this thesis stronger — the 3–5 pieces of work or evidence that would most reduce its fragility.

Output format

# Red Team — [Name / Thesis] | [Position: for / against / build / launch / invest / etc.] | [Date]
Materials reviewed: [list] | Web verification: [used / not used]

## The thesis, restated fairly
[2–3 sentences + unstated assumptions it quietly depends on.]

## The other side's best case (steelman)
[3–5 arguments, each with its strongest supporting evidence — sourced where
verified, labeled "logic, unverified" where not. Ends with their rebuttal to
the user's best point.]

## Assumptions ranked by fragility
| # | Assumption | Load-bearing? | Support level | Fragility |
|---|---|---|---|---|
| 1 | [assumption] | Critical / Major / Minor | Verified / Inference / Hope | HIGH/MED/LOW |

**The fragile quadrant:** [the critical-but-weakly-supported assumptions, in plain words.]

## Falsifiability map
| Assumption | Falsifiable? | What would falsify it | Where/when it would show up |
|---|---|---|---|

**Unfalsifiable elements:** [the faith-based parts, named as such.]

## Kill criteria (pre-commit)
1. If [observable condition] by [timeframe] → thesis broken.
...
*(Evidence-based, not outcome-based. Budget stops, price stops, and
stage gates are the user's governance process.)*

## Cognitive traps in the write-up
- **[Trap]:** > "[quoted language]" — [why it's the trap, one line]

## What would make this thesis stronger
[3–5 concrete pieces of work, ordered by how much fragility they remove.]

## Bottom line
[2–3 sentences: where the thesis is genuinely strong, where it's most likely
to die, and the single most important thing to resolve. Not a recommendation.]

Guardrails

  • Attack with evidence or label it logic. The steelman may not invent data — every factual claim is either sourced (with as-of date) or explicitly tagged as an unverified logical argument.
  • Never fabricate numbers, quotes, competitor moves, customer reactions, or "what the market thinks." A red team that makes things up teaches the user to ignore red teams.
  • Steelman, not strawman. If the opposing case isn't one a smart opponent would actually run, rewrite it.
  • Quote the write-up when flagging bias. Trap-naming without the offending sentence is name-calling.
  • Brutal ≠ contrarian theater. If the thesis is genuinely strong somewhere, say so — credibility of the attack depends on conceding the strong points.
  • No recommendation. The output is a stress test; whether to proceed, scale, delay, or pass stays with the user. Kill criteria are about evidence, never advice to act at a particular number.
  • Respect the domain's base rates. Where the plan belongs to a class with a known track record (new product launches, large IT migrations, post-merger integrations, market entries), name the class and ask whether the write-up explains why this case beats the class — but do not invent a statistic for the base rate.

Quality checks

  • Thesis restatement the user would sign
  • Steelman includes the opponent's rebuttal to the user's best argument
  • Every critical assumption has a falsifiability entry
  • Kill criteria are observable, time-bound, and evidence-based (no single-metric or price triggers)
  • Every bias flag quotes the write-up
  • "What would make it stronger" section present — the red team must be constructive

Example prompts

"Attached is our plan to launch a self-serve tier alongside the enterprise product next quarter. Red-team it: steelman the case that it cannibalizes enterprise, rank my assumptions by fragility, tell me what would falsify each one, define kill criteria, and call out any motivated reasoning in my own language. Don't be polite."

"Here's the business case for opening a second clinic location. Pre-mortem it — assume it failed 18 months from now and tell me the most likely reasons, then give me the evidence I should be watching for in the first 90 days."

"This is my memo arguing we should replace our agency with an in-house marketing team. Argue the agency's side better than they would, and show me which of my cost assumptions are hope rather than data."

"Attached is my long write-up on a listed infrastructure company. Red-team it: steelman the bear case, rank the assumptions, define evidence-based kill criteria, and flag anchoring in my valuation section."

"We're proposing to the city council that the transit route be rerouted. Steelman the opposition, tell me which of our ridership assumptions are unfalsifiable, and give me the questions we'll be asked that we can't currently answer."

Works well with

Draft the plan with decision-memo-drafter, then bring it here before it goes to the decision-makers. Use hundred-day-plan-drafter after the thesis survives — the kill criteria become the first-90-day watch list. Use expert-interview-synthesis to gather the disconfirming evidence the red team says is missing.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.