Red Team

Every other way of using an AI helps your idea. This one tries to kill it — on purpose, before reality does it for you at full price.

The instinct when you have an idea is to seek confirmation. You ask a friend; they're invested in you, so they're kind. You ask an assistant; it's trained to be helpful, so it's encouraging. You ship. Then the customer doesn't buy, the launch is quiet, the six-month bet is gone, and you never find out exactly which assumption was the one that was wrong. Almost no failed idea was hopeless. Most just never got attacked hard enough by someone trying to make it fail.

After 9/11 the CIA had this problem at the highest possible cost — they had not stress-tested their own assumptions hard enough. Their answer was the Red Cell: a team whose only job was to attack the agency's own thinking and, in the director's words, "make senior officials feel uncomfortable." In 2009 the CIA declassified the playbook — A Tradecraft Primer: Structured Analytic Techniques for Improving Intelligence Analysis (public, on cia.gov). This skill turns the four sharpest techniques from that document into an adversarial panel you can run on your own idea.

The goal is not negativity. It's to surface the objections that are load-bearing — the ones that, if true, mean the thing dies — while they're still cheap to fix. A good red team ends one of two ways: the idea is dead, or it's bulletproof. Both save you six months. The only failure is a comfortable analysis that flatters you and misses the thing that was always going to get you.

When to use this

Trigger on any request to critique, pressure-test, pre-mortem, or find the weakness in something the user is weighing or has built: a product, a feature, a launch plan, a pricing model, a go-to-market motion, a business model, a strategic bet, an architecture decision, a pitch, a tweet, a resignation email. Also trigger on the softer asks — "does this actually make sense," "what would make this fail," "steelman the case against," "why wouldn't people use this."

Do not use it when the user needs a builder or a helper rather than a critic — writing the thing, fixing the bug, answering a fact. Red team attacks a proposal; it does not produce one. If there's no clear target to attack, ask for one first — a fuzzy target produces fuzzy attacks.

The method: four techniques, run in parallel, then synthesized

The power here is independence. If one analyst runs all four techniques in sequence, the later ones anchor to whatever the first one found, and the analysis collapses into a single narrative — usually the first weakness it noticed. Real red cells put different people in different rooms precisely so their blind spots don't overlap. Reproduce that: run each technique as its own subagent, blind to the others, and only combine the findings after all four are back.

Each technique attacks from a different direction and catches a different class of failure. They are chosen to barely overlap:

Read each technique's full brief before dispatching it:

• techniques/key-assumptions-check.md
• techniques/devils-advocacy.md
• techniques/competing-hypotheses.md
• techniques/red-team-analysis.md

Background on the source and how these fit together: references/tradecraft-primer.md.

How to run a red team

1. Frame the target

Restate, in one or two sentences, exactly what is being red-teamed and what "success" would mean for it. The techniques need a fixed target. If the user gave a specific angle ("why people would never use our tools"), let it sharpen the emphasis — but still run all four. The angle someone is already worried about is rarely the thing that actually kills the project; running the full panel is how you catch the failure they didn't think to ask about.

Then gather real context before dispatching — from the conversation, from files, from memory, from the product itself. The techniques are only as sharp as the facts they're given; an analyst working from a one-line description will invent details, and invented weaknesses waste everyone's time. Assemble one context packet and hand the same one to all four.

2. Dispatch all four techniques in parallel

Spawn four subagents in a single turn — one per technique — so they run concurrently and independently. Give each one:

• The framed target and the success definition
• The shared context packet
• The full brief for that technique from techniques/
• The instruction to return findings in the shared finding format (below)

Push every technique to be specific and concrete. "Users might not trust it" is worthless; "an author who already paid for Vellum and a Reedsy editor has no reason to move their manuscript into a third tool the week before launch" is something you can act on. Make them name the exact person, the exact moment, the exact number. Tell each one to rank its own findings by lethality and to be honest when an attack doesn't land — a technique that manufactures ten weak objections is worse than one that lands two real ones and says so. Calibration is part of the job.

3. Synthesize the kill-memo

When all four return, combine them — do not just staple four reports together; that's four documents, not a red team. Read references/synthesis.md for the method. In short: dedupe overlapping findings, rank everything by lethality across all four techniques, separate the load-bearing objections (true → it dies) from the survivable ones, write an honest counter to each top objection, and end on a single verdict.

Shared finding format

Each technique produces its own native analysis (an assumptions table, one big argument, a hypothesis matrix, an actor-by-actor read) and normalizes its results into findings in this shape, so synthesis can merge across all four:

### [Short, sharp title — the objection in one line]
**Technique:** Key Assumptions Check | Devil's Advocacy | Competing Hypotheses | Red Team Analysis
**Lethality:** Fatal | Serious | Nagging
**The attack:** 2-4 sentences. Concrete. Names the person / moment / number. Steelmanned — the strongest version of the objection, not a strawman.
**What would have to be true for this NOT to kill it:** The condition under which the idea survives this attack. The fix hides here.

Fatal = if true, the thing does not work and no execution saves it. Serious = a major wound that needs a real answer but is survivable with the right move. Nagging = a genuine friction worth noting, not existential.

Output structure

Deliver the synthesized kill-memo in this shape:

# Red Team: [target]

**Verdict:** [Bulletproof / Survives-if / Kill] — one sentence on why.

## The load-bearing objections
[The 2-4 findings ranked Fatal or high-Serious that actually decide the outcome. For each: the attack, and an honest counter — does it hold, or does it fold?]

## The full board
[Every deduped finding, grouped by lethality, one line each — the complete attack surface.]

## If you do only three things
[The three highest-leverage moves that neutralize the most lethal objections. Concrete and specific.]

## Where the idea held
[Brief and honest: the ground the red team could NOT take — what's genuinely strong, and which attacks failed. A red team that finds nothing strong is flattering itself in reverse; real analysis cuts both ways.]

Keep the verdict honest. If the idea is strong, say so and show where the attacks broke against it. If it's in trouble, don't cushion it — the entire value of a red team is that it tells you the thing your friends won't.