Free Agent Skill
Premortem
Run a premortem — psychologist Gary Klein's technique of imagining a plan has already failed and working backward to explain why, which surfaces risks that forward planning misses because it counteracts the social and psychological pressure to seem confident.
Use when: the user is about to commit to a plan, launch, project, or big bet, when a group seems to have converged on optimism too quickly, or whenever premortem is explicitly requested. Best used before commitment, not after — if something has already failed, use postmortem-retro instead.
Install this skill
- Create a folder named `premortem`.
- Save the skill content below as `SKILL.md` inside that folder.
- Place the folder in `~/.codex/skills/` for Codex, `.cursor/skills/` for Cursor or `.claude/skills/` for Claude Code.
- Describe the task normally. Your agent loads the skill when its description matches.
---
name: premortem
description: Run a premortem — psychologist Gary Klein's technique of imagining a plan has already failed and working backward to explain why, which surfaces risks that forward planning misses because it counteracts the social and psychological pressure to seem confident. Use this whenever the user is about to commit to a plan, launch, project, or big bet, when a group seems to have converged on optimism too quickly, or whenever premortem is explicitly requested. Best used before commitment, not after — if something has already failed, use postmortem-retro instead.
---
# Premortem
Teams that feel good about a plan tend to suppress doubts — voicing
concern feels like disloyalty or pessimism. A premortem removes that
pressure by making failure the assumed starting point, which makes
raising risks feel like the *helpful* thing to do rather than the
negative thing.
## The technique
Frame it exactly like this, don't soften it: **"It's [some point in the
future]. This has failed completely. What happened?"**
Then generate specific, concrete reasons — not vague ones. "It failed
because of poor execution" is not a premortem finding. "The vendor missed
the integration deadline by six weeks because nobody owned the
dependency" is.
Push for a real list, not one obvious answer:
1. Generate at least 5-8 distinct failure stories before evaluating any
of them. Breadth first, judgment second — evaluating too early kills
the quieter, weirder failure modes that turn out to matter most.
2. For each one, ask: is this preventable, detectable early, or just a
risk we accept? Sort them into those three buckets.
3. For "preventable," name the specific change to the plan now.
4. For "detectable early," name the leading indicator to watch for and
who's watching it.
5. For "accept," say so explicitly rather than letting it go unspoken —
an accepted risk that's written down is very different from one nobody
noticed.
## Common failure categories worth checking explicitly
- **Dependency failure** — something outside your control that the plan
quietly assumes will go right.
- **Timeline compression** — the plan assumed the best case for how long
things take, not the typical case.
- **Adoption/behavior** — the plan assumes people will act differently
than they have before, without a mechanism forcing that change.
- **Second-order reaction** — a competitor, regulator, or stakeholder
responds in a way the plan didn't model.
- **Silent single point of failure** — one person, system, or assumption
that everything else quietly depends on.
## Output
A short list of concrete failure stories, sorted into
prevent/detect/accept, with the plan changes that follow from the
"prevent" bucket stated explicitly. Don't just list risks — say what
changes about the plan as a result.
More free skills
Prompt Refiner
Turns a vague request into an executable brief without silently inventing missing requirements.
Decision Framer
Separates the real choice from noise, then tests options against explicit criteria and uncertainty.
Meeting to Actions
Converts messy notes into decisions, owned actions, deadlines and unresolved questions.
Calibrated Forecasting
Turn a vague prediction or unstated confidence level into an explicit, calibrated probability estimate, following the practices Philip Tetlock found separated "superforecasters" from everyone else — breaking questions into sub-questions, checking base rates, updating in small increments as new information arrives, and tracking predictions against outcomes.
Decision Memo
Structure a real, consequential decision as a written narrative memo in the style Jeff Bezos used at Amazon — full sentences and paragraphs rather than bullet points, forcing the logic to be checked rather than gestured at, plus explicit classification of whether the decision is reversible (a "two-way door") or not (a "one-way door").
Feynman Teachback
Test and build genuine understanding of a concept using the Feynman technique — explain it as simply as possible, notice exactly where the simple explanation breaks down, and treat that break point as the thing to actually go learn.
First Principles
Rebuild a problem from fundamental truths (physics, economics, unit costs, what's actually true regardless of convention) rather than by analogy to how things are normally done — the reasoning style associated with Elon Musk's approach to manufacturing cost problems and Richard Feynman's approach to physics problems.
Focus and Tradeoffs
Cut a bloated plan, roadmap, or list of priorities down to the one or two things that actually matter, in the tradition associated with Steve Jobs's product focus — "innovation is saying no to a thousand things."
Jobs to Be Done
Diagnose what "job" a customer is actually hiring a product, service, or workaround to do, using the Jobs-to-be-Done framework (Clayton Christensen's "progress in a specific circumstance," Bob Moesta's forces-of-progress and switch interview, Tony Ulwick's job statements and desired-outcome scoring).
Mental Models
Apply Charlie Munger's "latticework" approach — a small set of cross-disciplinary thinking tools (inversion, second-order effects, incentives, circle of competence, opportunity cost, base rates) to frame a vague or general problem.
Moat Analysis
Assess whether a competitive advantage is durable (a real "moat," in Warren Buffett and Charlie Munger's terms) or temporary, by checking it against the standard sources of durable advantage — switching costs, network effects, economies of scale, brand/trust, and regulatory or IP protection — rather than taking "we're ahead right now" at face value.
Negotiation Prep
Prepare for a high-stakes negotiation or hard conversation using tactical-empathy techniques associated with former FBI negotiator Chris Voss — labeling emotions, calibrated open-ended questions, mirroring, and getting to genuine "that's right" rather than a grudging "yes."
Postmortem / Retro
Extract a specific, reusable lesson after something succeeded or failed, following the principle (associated with Ray Dalio's "pain plus reflection equals progress") that outcomes only compound into better judgment if they're deliberately converted into a written, checkable lesson rather than just felt and moved past.
Want this skill connected to a complete workflow?
Every skill is free and works independently. We can connect it to your tools, context, approval steps and other agents as a designed, tested pipeline for your business.