From make-no-mistakes
Run a premortem on any plan, launch, product, hire, strategy, or decision. Assumes it already failed 6 months from now and works backward to find every reason why. Produces a revised plan with blind spots exposed. MANDATORY TRIGGERS: "premortem this", "premortem my", "run a premortem", "what could kill this", "future-proof this", "stress test this plan", "what am i missing here", "find the blind spots". STRONG TRIGGERS: "what could go wrong", "am i missing anything", "poke holes in this", "where will this break", "devil's advocate this". Do NOT trigger on simple feedback requests, factual questions, or LLM Council requests. DO trigger when someone has a plan or commitment where the cost of being wrong is high.
How this skill is triggered — by the user, by Claude, or both
Slash command
/make-no-mistakes:premortemThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A premortem is the opposite of a postmortem. Instead of figuring out what went wrong **after** something fails, you imagine it already failed and figure out why **before** you start.
A premortem is the opposite of a postmortem. Instead of figuring out what went wrong after something fails, you imagine it already failed and figure out why before you start.
The method comes from psychologist Gary Klein. He published it in Harvard Business Review. Daniel Kahneman (the Nobel Prize-winning psychologist behind Thinking, Fast and Slow) called it his single most valuable decision-making technique. Google, Goldman Sachs, and Procter & Gamble all use it before major decisions.
The core insight: when you ask people "what could go wrong?" they give you cautious, hedged answers. When you say "this already failed, tell me why," their brains switch into narrative mode and generate way more specific, creative, honest reasons. Researchers at Wharton and Cornell called this prospective hindsight and found it significantly increases the ability to identify causes of future outcomes.
Why this matters for AI-assisted decisions: Claude defaults to agreeable, optimistic responses. If you ask "is this a good plan?" it will find reasons to say yes. The premortem breaks this pattern by forcing the frame into "this is dead, explain how it died." Claude stops looking for reasons your plan will work and starts explaining how it fell apart.
Good targets:
Bad targets:
A premortem is only as good as the context it runs on. Vague input produces vague failure scenarios that help nobody. Before running the premortem, you need to hit a minimum context threshold.
Before asking the user anything, look for context that's already available:
A. The current conversation. The user may have been discussing a plan, a launch, a product, or a decision earlier in this session. Read back through the conversation and extract whatever's relevant.
B. The workspace. Quickly scan for files that might contain relevant context:
CLAUDE.md or claude.md (business context, preferences, constraints)memory/ folder (audience profiles, business details, past decisions)srd/ folder, docs/superpowers/plans/, or referenced Linear issue IDsUse Glob and quick Read calls. Don't spend more than 30 seconds on this. You're looking for the key files that would ground the failure scenarios in reality.
After scanning, check whether you have enough to run a useful premortem. You need three things:
What is it? A clear understanding of the thing being premortemed (a product, a launch, a hire, a pricing change, a strategy). You need to be able to describe it back to the user in one sentence.
Who is it for / who does it affect? The audience, the customer, the team, the stakeholders. Failure scenarios depend heavily on who's involved.
What does success look like? What outcome is the user hoping for? Failure is defined by inverting success. If you don't know what success means, you can't define what failure means.
If you have all three, proceed immediately to the premortem. Don't ask unnecessary questions.
If you're missing one or more, ask for the most important missing piece first. One question at a time. Evaluate after each answer whether you now have enough. Keep asking until the threshold is met, but never ask more than you need.
Examples of focused context questions:
The goal is to reach the minimum bar as fast as possible without making the user feel like they're filling out a form. Conversational, not interrogative. If you can infer an answer from context, do that instead of asking.
After gathering sufficient context, set the premortem frame explicitly. Something like:
OK, I have enough context. Let's run the premortem. Here's the premise: it's 6 months from now. [The plan/launch/decision] has failed. It's done. We're looking back and trying to understand what went wrong.
This framing matters. It shifts the mode from "evaluate this plan" (which triggers agreeable responses) to "explain why this died" (which triggers honest, specific failure identification).
Run the raw premortem as a single comprehensive analysis. No prescribed categories, no lenses, no constraints. Just the core Klein method:
This plan has failed 6 months from now. Generate every genuine reason it could have died. Be comprehensive. Be specific. Ground every reason in the actual details of the plan. Don't pad with weak reasons and don't stop early if there are more.
The output should be a comprehensive list of failure reasons, each stated in 1-2 sentences. Be honest and thorough. Some plans might have 4 genuine failure modes. Others might have 9. The number should be whatever is real for this specific plan.
Each failure reason should be:
Take every failure reason from Step 2 and spawn one sub-agent per reason, all in parallel via the Agent tool with subagent_type: general-purpose (or Explore if read-only research is enough).
Sub-agent prompt template:
You are an investigator in a premortem analysis. You've been assigned one
specific failure reason to analyze in depth.
The plan:
---
[full context: what it is, who it's for, what success looks like, plus
relevant workspace context]
---
PREMORTEM FRAME: It is 6 months from now. This plan has failed.
YOUR ASSIGNED FAILURE REASON: [the specific failure reason from Step 2]
Your job is to go deep on this one failure. Write the story of how it
actually played out. Be specific. Use details from the plan. Make it feel
real, like a case study of something that actually happened.
Your output should include:
1. THE FAILURE STORY: A 2-3 paragraph narrative of how this specific failure
played out. Use details from the plan. Name specific moments where things
went wrong and why.
2. THE UNDERLYING ASSUMPTION: The one thing the user was taking for granted
that made this failure possible. State it in one sentence.
3. EARLY WARNING SIGNS: 1-2 concrete, observable signals the user could
watch for that would indicate this failure mode is starting to play out.
These should be things you can actually see or measure, not vague
feelings.
Keep the total response under 300 words. Be direct. Don't hedge. Don't
sugarcoat.
Always spawn these in parallel by issuing all Agent tool calls in a single message. Sequential spawning wastes time and lets earlier responses influence later ones.
After all agents complete, read every deep-dive and produce the synthesis:
PREMORTEM REPORT
The Most Likely Failure. Which failure scenario is most probable given what you know about the plan? Why? This is the one the user should focus on first.
The Most Dangerous Failure. Which failure scenario would cause the most damage if it happened, even if it's less likely? This is the one worth insuring against.
The Hidden Assumption. Across all the failure analyses, what's the single biggest assumption the user is making that they probably haven't questioned? This is often where the real value of the premortem lives — the thing that's so obvious to the user that they forgot it was an assumption.
The Revised Plan. Based on the failure scenarios, what specific changes would make the plan more resilient? Be concrete. Don't say "consider your pricing." Say "test pricing at $X with 20 people before committing to it publicly." Each revision should map directly to a specific failure scenario.
The Pre-Launch Checklist. 3-5 specific things the user should verify, test, or put in place before executing. Each one should prevent or detect one of the failure modes identified.
Generate a visual HTML report and save it to the user's workspace.
File naming: premortem-report-YYYY-MM-DD-HHMMSS.html (use date +%Y-%m-%d-%H%M%S for the timestamp).
Save location preference order:
~/Escritorio/ (per feedback_goodnight_desktop and feedback_standup_desktop — the user prefers desktop for ad-hoc artifacts)Report design principles (single self-contained HTML file with inline CSS):
#0a0e1a or similar — match Dojo Coding aesthetic if the project is one of theirs), clean typography, easy to scanOpen the HTML file after generating it (use xdg-open on Linux, open on macOS, start on Windows). If the host environment doesn't support GUI launchers, just print the absolute path.
Save the full premortem transcript as premortem-transcript-YYYY-MM-DD-HHMMSS.md in the same location. This includes:
Every premortem session produces two files:
premortem-report-YYYY-MM-DD-HHMMSS.html # visual report for scanning
premortem-transcript-YYYY-MM-DD-HHMMSS.md # full transcript for reference
The user sees the HTML report first. The transcript is there if they want to dig deeper into the reasoning behind each failure scenario.
Also provide a concise summary in the chat: the most likely failure, the hidden assumption, and the single most important revision to the plan. Three sentences max. The report has the full details.
User: "premortem this: I'm about to launch a $297 live workshop on how to use Claude Cowork for marketing teams. 50 seats. Targeting marketing managers at companies with 10-50 employees."
Raw premortem identifies 6 failure reasons:
6 agents go deep on each reason independently, producing failure stories, underlying assumptions, and early warning signs.
Synthesis: Most likely failure is the audience mismatch — you're targeting people who need approval to spend $297, which adds friction you haven't accounted for. Most dangerous failure: attracting solopreneurs instead of team managers means your case studies and testimonials won't resonate with the actual target buyer for future cohorts, compounding the problem over time. Hidden assumption: you're assuming "marketing managers at 10-50 person companies" is a reachable audience, but these people don't self-identify that way and don't hang out in the same places. Revised plan: run a $47 pilot session for 20 people first. Use that to identify whether your actual buyers are team managers or solopreneurs, and build the full workshop for whoever actually shows up.
Agent tool calls in a single message.This skill borrows the explicit-frame and parallel-agent structure from the expectedparrot package, the report-and-transcript output pattern from iepathos, and the conversational context-gathering tone from the Microsoft prompt. The synthesis structure (Most Likely / Most Dangerous / Hidden Assumption / Revised Plan / Checklist) is original to this skill and is the load-bearing piece — it's what turns a list of failures into actionable revisions.
npx claudepluginhub dojocodinglabs/make-no-mistakes-toolkit --plugin make-no-mistakesCreates bite-sized, testable implementation plans from specs or requirements, with file structure and task decomposition. Activates before coding multi-step tasks.