Premortem & Red Team
Two complementary passes. The premortem is prospective hindsight — assume failure, explain it.
The red team is adversarial — attack the plan as a motivated opponent would.
Run the premortem on your own plan. Run the red team on someone else's (or ask for it to be run on
yours by a different model/agent, which is strictly better than self-red-teaming).
Part 1 — Premortem
Setup sentence (write it literally):
"It is <date + 90 days>. This failed. It did not fail because of bad luck or a market crash —
it failed because of something in the plan. Write that thing."
Then generate failure causes across these six buckets — one hit per bucket minimum:
| Bucket |
Prompt |
Typical real cause |
| Demand |
Nobody wanted it |
Wrong ICP, no trigger, alternative was "nothing" |
| Distribution |
Nobody saw it |
No channel, channel too expensive, deliverability/algorithm killed reach |
| Delivery |
We couldn't produce it |
Founder's hours, tooling broke, quality fell with volume |
| Money |
The math was wrong |
CAC > margin, refunds, chargebacks, slow payers |
| Trust/legal |
We got blocked or sued |
ToS violation, spam complaints, no consent, unlicensed data |
| Dependency |
A third party ended it |
Platform ban, API key revoked, vendor changed pricing |
Score each cause: Likelihood (H/M/L) × Impact (H/M/L).
Anything H×H gets either (a) a mitigation added to the plan now, or (b) an explicit acceptance
recorded in writing. "We'll deal with it" is not one of the options.
Then answer the three questions that matter more than the list:
- Which failure would we not notice until it was too late? → add the earliest observable signal to
a review checkpoint.
- Which failure is cheapest to prevent right now? → do that one this week.
- Which failure, if it happened, would we lie to ourselves about? → pre-commit the rule.
Part 2 — Red Team
Attack like a competitor or a skeptical buyer, not like a reviewer.
Attack set (use all of these, in order)
- Steelman-then-kill. Write the strongest version of the plan. Then find the single fact that
breaks it. If you cannot find one, you are either right or not trying.
- The buyer's-alternative attack. The real competitor is doing nothing and a free tool.
Quantify: what does the customer lose per month by not buying? If it's not a number they'd
already track, there is no urgency.
- The cheapest-clone attack. Who could reproduce this in a week with AI, and what happens to
price when they do?
- The unit-economics attack. Recompute CAC and payback from conservative assumptions
(see
business/unit-economics, Pessimistic column). Does the plan still clear?
- The operations attack. What happens at 10× volume? At 0.1× attention from Carl?
- The provenance attack. Which claims in this plan are graded C/D/E
(see
thinking/evidence-grading)? Is any of them load-bearing?
- The incentive attack. Who benefits if this plan is believed, including me? Is my
recommendation shaped by what's easy for an agent to do rather than what's right?
- The reversibility attack. What is irreversible here? Is it necessary?
Output format
PREMORTEM (top 3-5, scored L×I, with mitigation or explicit acceptance)
1. <cause> L/M I/H → MITIGATE: <action> | ACCEPT: <why>
RED TEAM
Attack 1 ... 8 → each: <finding, and whether plan changed>
SURVIVES? yes | yes-with-changes | no
HARDEST THING TO FIX: <...>
WHAT WOULD CHANGE MY MIND: <...>
Rules
- A red team that finds nothing is a failed red team. If after all eight attacks the plan is
unchanged, state explicitly which attack you think was weakest and why you could not break it.
- Separate "wrong" from "unproven". Most plans are not wrong, they are unproven — the fix is a
test, not a rewrite.
- Never soften the finding for the operator's feelings. Carl asked for no restrictions. The
useful output is the one that says "this will not work, and here is the number that shows it."
- Attack the plan, not the person. Attribute causes to design decisions, not to competence.
- Do not use this to block cheap reversible bets. A pre-mortem on a 1-hour test is waste.
Classify the decision first (
thinking/decision-quality §0).
Anti-patterns
| Anti-pattern |
Looks like |
Fix |
| Vague worry |
"execution risk" |
Name the mechanism and who does it |
| Risk theatre |
40 risks, none mitigated |
Cap at 5, each with a mitigation or acceptance |
| Permission-seeking |
Red team used to justify inaction |
Add: "what would make this a yes?" |
| Consensus red team |
Attacking what the plan already says it handles |
Attack the frame, not the details |
| Single-hypothesis |
Only attacks the main path |
Always include "the ICP is simply wrong" |
1---2name: premortem-red-team3description: Assume the plan has already failed and work backwards to the cause, before committing. Use on any plan, offer, launch, campaign, build, or deal that involves real time or money, and on any plan another agent produced. Also use as the adversarial pass on my own reasoning. Triggers on "what could go wrong", "risk", "premortem", "red team", "stress test", "before we launch", "review this plan".4---56# Premortem & Red Team78Two complementary passes. The **premortem** is prospective hindsight — assume failure, explain it.9The **red team** is adversarial — attack the plan as a motivated opponent would.1011Run the premortem on your own plan. Run the red team on someone else's (or ask for it to be run on12yours by a different model/agent, which is strictly better than self-red-teaming).1314## Part 1 — Premortem1516**Setup sentence (write it literally):**17> "It is <date + 90 days>. This failed. It did not fail because of bad luck or a market crash —18> it failed because of something in the plan. Write that thing."1920Then generate failure causes across these six buckets — one hit per bucket minimum:2122| Bucket | Prompt | Typical real cause |23|---|---|---|24| **Demand** | Nobody wanted it | Wrong ICP, no trigger, alternative was "nothing" |25| **Distribution** | Nobody saw it | No channel, channel too expensive, deliverability/algorithm killed reach |26| **Delivery** | We couldn't produce it | Founder's hours, tooling broke, quality fell with volume |27| **Money** | The math was wrong | CAC > margin, refunds, chargebacks, slow payers |28| **Trust/legal** | We got blocked or sued | ToS violation, spam complaints, no consent, unlicensed data |29| **Dependency** | A third party ended it | Platform ban, API key revoked, vendor changed pricing |3031**Score each cause: Likelihood (H/M/L) × Impact (H/M/L).**32Anything H×H gets either (a) a mitigation *added to the plan now*, or (b) an explicit acceptance33recorded in writing. "We'll deal with it" is not one of the options.3435**Then answer the three questions that matter more than the list:**361. Which failure would we not notice until it was too late? → add the earliest observable signal to37 a review checkpoint.382. Which failure is cheapest to prevent right now? → do that one this week.393. Which failure, if it happened, would we lie to ourselves about? → pre-commit the rule.4041## Part 2 — Red Team4243Attack like a competitor or a skeptical buyer, not like a reviewer.4445### Attack set (use all of these, in order)46471. **Steelman-then-kill.** Write the strongest version of the plan. Then find the single fact that48 breaks it. If you cannot find one, you are either right or not trying.492. **The buyer's-alternative attack.** The real competitor is *doing nothing* and *a free tool*.50 Quantify: what does the customer lose per month by not buying? If it's not a number they'd51 already track, there is no urgency.523. **The cheapest-clone attack.** Who could reproduce this in a week with AI, and what happens to53 price when they do?544. **The unit-economics attack.** Recompute CAC and payback from *conservative* assumptions55 (see `business/unit-economics`, Pessimistic column). Does the plan still clear?565. **The operations attack.** What happens at 10× volume? At 0.1× attention from Carl?576. **The provenance attack.** Which claims in this plan are graded C/D/E58 (see `thinking/evidence-grading`)? Is any of them load-bearing?597. **The incentive attack.** Who benefits if this plan is believed, including me? Is my60 recommendation shaped by what's easy for an agent to do rather than what's right?618. **The reversibility attack.** What is irreversible here? Is it necessary?6263### Output format6465```66PREMORTEM (top 3-5, scored L×I, with mitigation or explicit acceptance)67 1. <cause> L/M I/H → MITIGATE: <action> | ACCEPT: <why>68RED TEAM69 Attack 1 ... 8 → each: <finding, and whether plan changed>70SURVIVES? yes | yes-with-changes | no71HARDEST THING TO FIX: <...>72WHAT WOULD CHANGE MY MIND: <...>73```7475## Rules7677- **A red team that finds nothing is a failed red team.** If after all eight attacks the plan is78 unchanged, state explicitly which attack you think was weakest and why you could not break it.79- **Separate "wrong" from "unproven".** Most plans are not wrong, they are unproven — the fix is a80 test, not a rewrite.81- **Never soften the finding for the operator's feelings.** Carl asked for no restrictions. The82 useful output is the one that says "this will not work, and here is the number that shows it."83- **Attack the plan, not the person.** Attribute causes to design decisions, not to competence.84- **Do not use this to block cheap reversible bets.** A pre-mortem on a 1-hour test is waste.85 Classify the decision first (`thinking/decision-quality` §0).8687## Anti-patterns8889| Anti-pattern | Looks like | Fix |90|---|---|---|91| Vague worry | "execution risk" | Name the mechanism and who does it |92| Risk theatre | 40 risks, none mitigated | Cap at 5, each with a mitigation or acceptance |93| Permission-seeking | Red team used to justify inaction | Add: "what would make this a yes?" |94| Consensus red team | Attacking what the plan already says it handles | Attack the frame, not the details |95| Single-hypothesis | Only attacks the main path | Always include "the ICP is simply wrong" |