{"slug": "how-i-use-premortems-with-claude-and-codex", "title": "How I use premortems with Claude and Codex", "summary": "A developer uses premortems—a technique popularized by Gary Klein—with AI coding agents Claude and Codex to surface hidden assumptions and failure modes before committing to implementation plans. The premortem prompt asks the model to assume a plan has already failed and explain why, yielding more actionable critiques than standard review questions. The developer created a skill for Claude Code and Codex that runs this failure frame and outputs the most likely failure, most dangerous failure, hidden assumption, revised plan, and checklist.", "body_md": "I started using premortems for a boring reason: I did not trust the default review question.\n\nWhen 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.\n\nBut 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.\n\nAt that point I want a second pass that tries to break the decision.\n\nSo I started asking for a premortem.\n\nThe 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.\n\nThat small change matters with LLMs.\n\nWeak:\n\n```\nIs this plan good?\n```\n\nBetter:\n\n```\nIt is six months from now. This plan failed.\nExplain how it happened. Be specific.\n```\n\nThe second prompt gives the model a different job. It is no longer approving the plan. It is reconstructing the failure.\n\n\"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.\n\nThat is easier to act on.\n\nI use premortems as a second check in two places.\n\nFirst, coding decisions.\n\nNot 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.\n\nSecond, ideas.\n\nBefore 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.\n\nIt is not a replacement for taste, tests, review, or talking to people. It is just a cheap extra check before the plan hardens.\n\nI 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.\n\nSo I made a small skill:\n\n[https://github.com/PabloNAX/premortem-skill](https://github.com/PabloNAX/premortem-skill)\n\nThere are other premortem prompts and agent workflows already out there. I made this one for how I actually use Claude Code and Codex:\n\nThe 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.\n\nThe skill expects a concrete plan. If the plan is too vague, it asks for the missing context instead of making things up.\n\nThen it runs the failure frame:\n\nThe output I want is small:\n\n```\nmost likely failure\nmost dangerous failure\nhidden assumption\nrevised plan\nchecklist\n```\n\nAfter that I can push on one part:\n\n```\nGo deeper on the rollback failure.\nAssume I only have two hours before starting the migration.\n```\n\nOne 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.\n\nNormal review would probably tell me to dump, restore, test, and keep a backup. True, but not sharp enough.\n\nThe premortem came back with a more useful failure story:\n\n```\nMost likely failure\nSQLite's loose typing allowed rows that Postgres rejects or coerces differently.\nThe import looks mostly fine, but a few records become wrong after cutover.\n\nMost dangerous failure\nThere is no rollback boundary. The app starts writing to Postgres, the migration\nhalf-succeeds, and the SQLite copy is no longer a clean source of truth.\n\nHidden assumption\nThe queries are portable and the database switch is mostly a connection string.\n\nRevised plan\n1. Restore into local Postgres first.\n2. Diff row counts and sample rows before switching anything.\n3. Put the database backend behind one env var.\n4. Run normal local use against Postgres for a day.\n```\n\nNone 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.\n\nI also ran the skill on the launch plan for the skill itself.\n\nThe 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.\n\nIt 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.\n\nThat 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.\n\nThe input has to be concrete.\n\nWeak:\n\n```\nPremortem my startup idea.\n```\n\nBetter:\n\n```\nPremortem this launch plan:\nI am releasing a Claude/Codex skill for premortems.\nAudience: developers who already use coding agents.\nGoal: get 10 serious trials from people who use it on a real plan.\nChannels: GitHub README, DEV article, LinkedIn post.\nConstraint: no fake production examples.\n```\n\nThat gives the model something to inspect: audience, goal, channel, constraint, and failure condition.\n\nSame for coding. \"Premortem my migration\" is weak. \"Premortem this SQLite to Postgres migration, solo, no staging, rollback required\" is useful.\n\nInstall for Claude Code:\n\n```\ngit clone --depth 1 https://github.com/PabloNAX/premortem-skill && ./premortem-skill/install.sh claude\n```\n\nInstall for Codex instead:\n\n```\ngit clone --depth 1 https://github.com/PabloNAX/premortem-skill && ./premortem-skill/install.sh codex\n```\n\nI 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.", "url": "https://wpnews.pro/news/how-i-use-premortems-with-claude-and-codex", "canonical_source": "https://dev.to/pablonax/how-i-use-premortems-with-claude-and-codex-46mm", "published_at": "2026-06-17 10:19:30+00:00", "updated_at": "2026-06-17 10:51:41.733992+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "developer-tools"], "entities": ["Claude", "Codex", "Gary Klein", "Daniel Kahneman", "Harvard Business Review", "SQLite", "Postgres"], "alternates": {"html": "https://wpnews.pro/news/how-i-use-premortems-with-claude-and-codex", "markdown": "https://wpnews.pro/news/how-i-use-premortems-with-claude-and-codex.md", "text": "https://wpnews.pro/news/how-i-use-premortems-with-claude-and-codex.txt", "jsonld": "https://wpnews.pro/news/how-i-use-premortems-with-claude-and-codex.jsonld"}}