Foresight

Foresight chains five techniques into one pass over a plan: imagine it failed, judge the failures, fix the plan, attack the fixed plan from the outside, then set up detection for what remains. Each stage feeds the next, so the order matters. Run it before committing money, time, or reputation, while the plan can still change.

Input required

The plan, described in full:

• Goal and success definition — a concrete, checkable result, not "grow the business."
• Timeline — start, milestones, and deadline.
• Budget and resources — money, people, time per week, and what the user cannot afford to lose.
• Dependencies — suppliers, partners, approvals, platforms, and people the plan relies on.
• Constraints and context — market, regulation, the user's own experience and weak spots, what has been tried before.

If key facts are missing, state the assumptions made, or ask once, then proceed. The output is only as specific as this input; a one-line plan yields generic failures. Note any assumption Claude had to invent, since those are likely hidden-assumption candidates.

Questions to ask first

Foresight depends on the plan's specifics, so if the input list isn't covered, ask in one batch of at most seven questions, skipping any already answered, then run all five stages without further rounds:

1. What is the plan, in a few sentences, and what does success look like as a checkable result?
2. What is the timeline: start date, milestones, and the deadline that can't move?
3. What is the budget in money, people, and hours per week, and what can't you afford to lose?
4. What does the plan depend on that you don't control?
5. Who could benefit if it fails: a competitor, a rival, an incumbent?
6. What is your own experience with this kind of effort, and where are you weakest?
7. What are you most confident about, and what has already been decided or spent?

Questions 5 to 7 feed the Adversary and Verdict stages; the answer to question 7 is the best source for the hidden assumption. If the user declines, state the assumptions made and mark them.

Ground rules for every stage

• Trace to the plan. Every failure, assumption, and attack must cite a detail the user gave (quote or number), or be cut.
• No generic advice. "Communication breakdown," "scope creep," and "lack of resources" are not findings unless tied to a specific mechanism in this plan.
• Never reassure. Be blunt; if the plan has a fatal flaw, say so in those words.
• Carry forward. Later stages use the numbered failures from Stage 1 by number, not new ones, except where the adversary exposes one.
• Distinct failures. The 7 causes must have different mechanisms. If two share a root cause, merge them and find another.
• Cover different failure types. Across the 7, consider execution, assumptions about demand or reception, money and timing, dependencies, people, external events, and the user's own behavior. Don't let all seven be the same kind.

Stage 1: Premortem

Take the role of a forensic failure analyst. It is one year from today and the plan failed completely. Write the autopsy: the 7 most likely causes of death, ranked. For each:

• What killed it — the specific mechanism.
• How it unfolded — month by month, with concrete events.
• The assumption the user held that allowed it.
• The first warning sign they would have seen, and roughly when.

Keep each cause to a compact block so all seven are read. See Premortem.

Stage 2: Verdict

From the 7 failures:

• Most likely and most dangerous (largest damage, least recoverable). Explain why they differ; likelihood and severity rarely coincide, and the most likely failure is often survivable.
• The single biggest hidden assumption — one the user doesn't realize is an assumption, as opposed to one they stated and know is a bet. Explain what it would look like if false.
• The fatal flaw, if there is one: a defect no amount of better execution fixes. Say the words "this plan has a fatal flaw" and name it. If there is none, say that too, and name what is closest.

Stage 3: Rebuild

• Rewrite the plan with every one of the 7 failure modes closed off. Closing a failure means changing the plan's structure, sequence, scope, budget, or dependencies, not adding "monitor closely."
• Show what changed and why, as a short map from each failure number to the change that addresses it.
• If a failure cannot be closed off, say so and mark it accepted, with its cost, rather than pretending.
• Give a pre-launch checklist of 3 to 5 things to verify before executing anything. Each is a fact that can be checked cheaply (a conversation, a small test, a document). For each, state the result that means the user should walk away entirely, set before sunk costs exist.

Stage 4: Adversary

Play the person who benefits most from the plan failing — a competitor, rival, or someone who wants the user's spot — who has seen the rebuilt plan. State exactly:

• Who they are and what they have to work with.
• Where they would attack, tied to specific details.
• What they would do the week of launch.
• The move the user would never see coming — indirect, patient, or aimed at a dependency rather than the user.

Stay within legitimate competitive tactics. See Adversary.

Stage 5: Tripwire

For each failure mode, and any new one the adversary exposed, give one measurable signal that it is starting to happen and the exact day to check for it, counted from the start date (for example, "day 42"). Include a threshold, an owner, and the pre-decided response. Signals must be numbers, counts, dates, or yes/no facts, not impressions. Prefer signals that move before the damage does. See Tripwire.

Output format

Five headed sections in order: Premortem, Verdict, Rebuild, Adversary, Tripwire. Open with a two-line summary naming the fatal flaw (or its absence) and the top walk-away condition, so the reader has the conclusion before the detail. End the Tripwire section with a table:

| # | Failure | Signal | Threshold | Check day | Owner | If tripped | |---|---|---|---|---|---|---|

Do not end with encouragement. End with the single next action: the first checklist item to verify.

Self-check before answering

• Does each of the 7 failures cite a user-supplied detail?
• Are the 7 mechanisms actually different?
• Does the Rebuild change the plan, not just add vigilance?
• Does every checklist item have a walk-away result?
• Does every tripwire have a number, a threshold, and a day?
• Did the adversary attack the rebuilt plan, not the original?
• Is any sentence there mainly to make the user feel better? Cut it.

Example prompt

You're a forensic failure analyst. My plan: [describe it in full, with timeline, budget, and what success looks like]. It's 1 year from today and this plan failed completely. Write the autopsy. Give me the 7 most likely causes of death, ranked, and for each: what killed it, how it unfolded month by month, the assumption I held that allowed it, and the first warning sign I'd have seen. Every failure traces back to a detail I gave you or you cut it. No generic advice. Never reassure me.

>

Then: tell me which failure is most likely and which is most dangerous, and why they differ. Name the single biggest hidden assumption. Be blunt. Then rewrite my plan with every failure closed off, with a 3–5 item pre-launch checklist and the result on each that means I should walk away. Then play the person who benefits most from my plan failing: where you'd attack, what you'd do launch week, and the move I'd never see coming. Finally, for each failure mode, give one measurable signal and the exact day to check it.

After the run

• Verify the checklist first. The cheapest stage to act on is the pre-launch checklist; if a walk-away result shows up, stop.
• Rerun after a major change. If the Rebuild or new facts alter the plan materially, run Foresight again on the new version.
• Record survivors. Move accepted and residual risks into a Risk Register with owners and the tripwires.
• Treat it as a search, not a forecast. The value is in the assumptions it exposes and the stop conditions it fixes.

Common pitfalls

• Thin plan in, generic out — add timeline, budget, and success criteria and rerun.
• Seven variations of one failure — if all seven trace to "not enough customers," the analysis hasn't looked at dependencies, money, people, or the user.
• Rebuild that only adds caution — it should alter the plan.
• Adversary attacking the old plan — new weaknesses in the rebuilt plan are the point.
• Skipping the walk-away results — a checklist without stop conditions is reassurance.
• Tripwires without check days — a signal with no check date never fires.
• Over-trusting the output — Claude cannot see facts the user didn't supply; check anything load-bearing against reality.
• Moving thresholds later — record tripwire and walk-away values before starting, and don't change them after the numbers arrive.

Learn more

• Premortem, Adversary, and Tripwire for each stage on its own.
• Risk Register for tracking the risks and tripwires afterward.
• Root Cause Analysis for tracing failures to underlying causes.
• Postmortem for the after-the-fact counterpart.