I started using premortems for a boring reason: I did not trust the default review question.
When I ask a coding agent "does this plan look good?", the answer is usually useful but too polite. It finds reasons the plan can work. It notices a few edge cases. It gives me a clean list of improvements. Fine.
But that is not the check I want right before I choose an implementation path, publish an idea, change auth, move data, or let an agent write a large diff.
At that point I want a second pass that tries to break the decision.
So I started asking for a premortem.
The frame
The method is Gary Klein's, not mine. He wrote about project premortems in Harvard Business Review in 2007. Daniel Kahneman later pointed to the technique as a practical way to push back on overconfidence. The idea is simple: assume the plan has already failed, then explain why.
That small change matters with LLMs.
Weak:
Is this plan good?
Better:
It is six months from now. This plan failed.
Explain how it happened. Be specific.
The second prompt gives the model a different job. It is no longer approving the plan. It is reconstructing the failure.
"What could go wrong?" often gives me a generic risk list. "This already failed, why?" gives me a story. The first break. The hidden assumption. The signal I would probably ignore. The rollback I forgot to design.
That is easier to act on.
Where I use it
I use premortems as a second check in two places.
First, coding decisions.
Not every code change needs this. I use it when the plan is still cheap to change but expensive to undo later: migrations, auth changes, data model changes, release plans, agent workflows that can touch many files, or anything where I am about to say "yeah, this should be fine" without enough friction.
Second, ideas.
Before I spend time on an article, a small open-source launch, or a product idea, I ask what would make it quietly fail. Not "is this interesting?" but "six weeks later nobody cared, what happened?" That usually surfaces a better problem than the one I was about to write about.
It is not a replacement for taste, tests, review, or talking to people. It is just a cheap extra check before the plan hardens.
Why I packaged it as a skill
I had been retyping the frame by hand. That worked, but it was inconsistent. Sometimes I asked too vaguely. Sometimes I let the answer become a generic list. Sometimes I forgot to force the model to revise the plan at the end.
So I made a small skill:
https://github.com/PabloNAX/premortem-skill
There are other premortem prompts and agent workflows already out there. I made this one for how I actually use Claude Code and Codex:
- short output in chat
- no HTML report
- one investigation per important failure mode
- a revised plan and checklist at the end
The chat output matters. If the result becomes a separate report I have to open, I read it later, which often means never. I want the critique in the same conversation while I still have the plan in my head.
What the skill does
The skill expects a concrete plan. If the plan is too vague, it asks for the missing context instead of making things up.
Then it runs the failure frame:
- Treat the plan as already failed.
- Generate failure modes that match the plan.
- Investigate the important ones separately.
- Synthesize the result into a short chat answer.
The output I want is small:
most likely failure
most dangerous failure
hidden assumption
revised plan
checklist
After that I can push on one part:
Go deeper on the rollback failure.
Assume I only have two hours before starting the migration.
Coding example
One side-project example: I wanted to move a small app from SQLite to Postgres over a weekend. Solo, no staging, a few months of real local data.
Normal review would probably tell me to dump, restore, test, and keep a backup. True, but not sharp enough.
The premortem came back with a more useful failure story:
Most likely failure
SQLite's loose typing allowed rows that Postgres rejects or coerces differently.
The import looks mostly fine, but a few records become wrong after cutover.
Most dangerous failure
There is no rollback boundary. The app starts writing to Postgres, the migration
half-succeeds, and the SQLite copy is no longer a clean source of truth.
Hidden assumption
The queries are portable and the database switch is mostly a connection string.
Revised plan
1. Restore into local Postgres first.
2. Diff row counts and sample rows before switching anything.
3. Put the database backend behind one env var.
4. Run normal local use against Postgres for a day.
None of that is exotic. That is the point. It found the boring failure I was most likely to skip. The rollback boundary changed the plan before I touched the migration.
Idea example
I also ran the skill on the launch plan for the skill itself.
The useful catch was simple: the repo explained the idea but did not show what the output looked like. A visitor would see install commands and text, but no proof of the experience. That changed the README. I recorded the short terminal demo and put it near the top.
It also pushed back on my metric. I was thinking about GitHub stars. The premortem pointed out that stars are easy to count and easy to optimize badly. A better signal would be a few people trying it on a real plan and telling me where the output was wrong.
That is the kind of critique I want. Not a big philosophical argument. A small correction before I spend more time on the wrong version of the idea.
How I ask
The input has to be concrete.
Weak:
Premortem my startup idea.
Better:
Premortem this launch plan:
I am releasing a Claude/Codex skill for premortems.
Audience: developers who already use coding agents.
Goal: get 10 serious trials from people who use it on a real plan.
Channels: GitHub README, DEV article, LinkedIn post.
Constraint: no fake production examples.
That gives the model something to inspect: audience, goal, channel, constraint, and failure condition.
Same for coding. "Premortem my migration" is weak. "Premortem this SQLite to Postgres migration, solo, no staging, rollback required" is useful.
Try it
Install for Claude Code:
git clone --depth 1 https://github.com/PabloNAX/premortem-skill && ./premortem-skill/install.sh claude
Install for Codex instead:
git clone --depth 1 https://github.com/PabloNAX/premortem-skill && ./premortem-skill/install.sh codex
I still ask agents to review plans. I just do not stop there anymore. For decisions that matter, I want one extra pass where the plan already failed and the agent has to tell me why.
Disclosure: I used AI assistance to draft and edit parts of this post. The examples and conclusions are from my own use of the premortem skill, and I reviewed the final text before publishing.
_
Sources
- Gary Klein, "Performing a Project Premortem," Harvard Business Review, 2007. https://hbr.org/2007/09/performing-a-project-premortem
- Daniel Kahneman, Thinking, Fast and Slow, 2011.
- D. J. Mitchell, J. E. Russo, N. Pennington, "Back to the future: Temporal perspective in the explanation of events," Journal of Behavioral Decision Making, 1989.
- M. Sharma et al., "Towards Understanding Sycophancy in Language Models," Anthropic, 2023. https://arxiv.org/abs/2310.13548
