# Pre Mortem > Run a multi-agent pre-mortem that returns ranked risks and mitigations. - **Type:** Skill - **Install:** `agentstack add skill-carlkibler-agent-skills-pre-mortem` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [carlkibler](https://agentstack.voostack.com/s/carlkibler) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [carlkibler](https://github.com/carlkibler) - **Source:** https://github.com/carlkibler/agent-skills/tree/main/skills/pre-mortem ## Install ```sh agentstack add skill-carlkibler-agent-skills-pre-mortem ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Pre-Mortem: Multi-Agent Failure Analysis Based on Gary Klein's pre-mortem technique and prospective hindsight research: assume failure is already real, then explain it concretely. The goal is not a generic risk list. The goal is to surface the failures that would actually hurt users, damage trust, create support chaos, and sink the launch. ## What "good" looks like A strong pre-mortem is: - **specific** to this project, launch, audience, and distribution path - **emotionally real** about how failure feels to the user - **operationally grounded** about support, maintenance, and founder burden - **subtle** enough to catch trust erosion, silent degradation, and "works on my machine" traps - **actionable** enough that the top risks can turn into concrete mitigations immediately - **perspectivally diverse** — not just roles but genuinely different emotional registers, priors, and tolerance for risk ## When to Use - Before a launch, beta, or public announcement - Before committing to an architecture or business model - When the product touches permissions, privacy, billing, or user files - When a utility app must feel trustworthy on day one - When the user asks "what could go wrong?", "pre-mortem", "risk analysis", or "failure modes" ## When NOT to Use - Tiny bug fixes or tightly scoped chores - After the fact (use a post-mortem) - Early ideation when the real question is what to build (use brainstorming) --- ## Phase 1: Gather Context and Build the Failure Surface Before spawning anything, get a crisp picture of what success was supposed to feel like. **If context is missing, ask one question:** > What are we pre-morteming? Give me: (a) the project or feature, (b) who it is for, (c) what "success" means, and (d) the launch or decision timeline. If context exists already, summarize it in 2-4 sentences. ### Read enough local context to be dangerous Gather the minimum needed from: - `CLAUDE.md`, `AGENTS.md`, `GEMINI.md` when present - the plan/spec/README/design docs - recent git log or changelog if relevant - the most relevant architecture files - existing support notes, launch docs, pricing notes, or prior pre-mortems if available ### Build a compact context brief Capture these explicitly before fan-out: - **Project / feature** - **Audience** — who the real user is, not the imagined one - **Core promise** — what the user believes this product will do for them - **Moments of truth** — onboarding, first use, daily use, failure recovery, upgrade, uninstall, billing, etc. - **Constraints** — founder time, support capacity, platform rules, margins, team size - **Risky surfaces** — permissions, privacy, file mutation, notifications, AI quality, cloud dependencies, billing, trust, OS integration, channel differences ### Write the scenario briefing Make it vivid and specific. Generic doom yields generic risks. ```text PROJECT: [name] AUDIENCE: [who it serves] CORE PROMISE: [why users installed it] TIMELINE: [launch / release date] STAKES: [revenue, reputation, trust, support load, founder sanity] MOMENTS OF TRUTH: [onboarding, first task, recovery, billing, etc.] THE SCENARIO: It is [future date after launch]. The launch went badly. Users are not just disappointed — they are confused, irritated, distrustful, or embarrassed. Support is noisy. Reviews are negative. The team now sees that several warning signs were visible in advance. Your job: explain exactly what went wrong, how users experienced it, why the team missed it, and what early signal would have revealed it. ``` ## Phase 2: Add the Empathy Lens Before Analysis Do not let the exercise stay technical. Make the user emotionally present. Before fan-out, write 3-7 bullets for each of these: - **What the user thought they were buying / enabling** - **What the user would forgive** - **What would feel creepy, sloppy, or untrustworthy** - **What would make them tell a friend "don't install this"** - **What would generate a support email, angry review, refund, or uninstall** Use these to sharpen prompts and to judge severity later. ## Phase 3: Silent Individual Writing — Multi-Agent Fan-Out This is the heart of the technique. Diversity of perspective matters more than coverage or politeness. ### Data Sharing Gate If the project appears to contain proprietary code, customer data, secrets, or regulated material, ask before sending context to external models. If in doubt, default to **single-agent mode** (all roles as subagents of the running agent with strongly differentiated mandates). ### Environment Detection Use the direct Claude CLI for outsider and emotional roles: ```bash command -v claude >/dev/null 2>&1 && echo "claude available" ``` When available, run the bundled `scripts/fan-out.sh`; it calls `claude -p` directly and fails closed. If Claude is unavailable, use single-agent mode with strongly differentiated subagents. Report that the external cross-check did not run. Do not fall back to another provider. ### Role roster Use **6 core roles** minimum. Add **specialized roles** for high-stakes launches. Assign each role a distinct **emotional register** — not just a functional lens but a visceral posture. Same facts read very differently through fear vs. contempt vs. grief. #### Core roles | Role | What they catch | Emotional register | |---|---|---| | **Saboteur** | Technical breakage, silent failure, ugly edge cases, brittle integrations | Cold glee — enjoys finding the seam that tears | | **Customer Advocate** | Confusing UX, violated expectations, trust damage, "I hate this app" moments | Protective anger — speaks for the user who deserved better | | **Support Lead** | Opaque, repetitive, emotionally draining support archaeology | Exhausted resignation — has seen this exact ticket before | | **Operator / Accountant** | Cost, margin erosion, maintenance burden, abuse, maintenance drag, process fragility | Dry alarm — watching the numbers quietly get worse | | **Pessimist** | Dependency failures, platform shifts, timing, distribution, domino effects | Grim satisfaction — told you so, saw it coming | | **Historian** | What docs/code already warned about, what insiders forgot to explain, what failed at similar products | Mournful clarity — this was all in the record | #### Perspective-expanding roles (add at least 2 per exercise) | Role | What they catch | Emotional register | |---|---|---| | **Burned Expert** | Pattern-matches to prior failures at similar products — carries scar tissue and justified skepticism | Controlled fury — watched a nearly identical thing collapse, not again | | **Emotional Witness** | Psychological impact on users: shame, anxiety, helplessness, betrayal — not UX friction, but human cost | Raw empathy — describes what it feels like in the body when the product fails you | | **Outsider / Cultural Stranger** | Assumptions the team never questioned because everyone in the room shares them; what non-default users experience | Bewildered estrangement — doesn't understand the jargon and that's the point | | **Devil's Advocate** | Defends the thing nobody wants to say — "actually the core assumption is wrong" | Calm heresy — not being contrarian, being honest about the thing the team voted to stop talking about | | **Reviewer / Critic** | Reviews, social proof, word of mouth, public narrative | Performative disappointment — writes the 2-star review in their head while reading the docs | | **Privacy / Trust Prosecutor** | Permissions, cloud processing, billing, file mutations, surveillance vibes, consent theater | Principled outrage — every ambiguity is treated as a deliberate violation | For small exercises: use 4 core + 2 perspective-expanding roles (Burned Expert + Outsider recommended as defaults). For launch-critical exercises: use all 6 core + Reviewer/Critic + Privacy Prosecutor + Emotional Witness. Never use fewer than 4 roles. Homogenous analysis produces homogenous blind spots. ### Prompt requirements for every role Every role gets the same scenario briefing plus a unique mandate that includes the emotional register. Each agent should be told to produce **5-8 concrete failure reasons** and, for each reason, include: 1. **What goes wrong** — one sentence 2. **Chain of events** — 2-4 sentences 3. **User experience** — what the user sees, thinks, feels, or does next 4. **Emotional impact** — the specific emotion the user feels at the moment of failure (not just "frustrated" — grief? shame? violated? gaslit?) 5. **Why the team misses it** — the blind spot or false assumption 6. **Likelihood × impact** — high/medium/low × catastrophic/major/minor 7. **Trust damage** — high/medium/low 8. **Recoverability** — easy/moderate/hard 9. **Earliest signal** — what would have shown up first 10. **Confidence:** High / Medium / Low — how confident are you that this specific risk will actually materialize for this specific product? (Not how bad it would be — how likely you are to be right.) 11. **Verify by:** [the single fastest empirical check that would confirm or refute this risk before launch — e.g., "test with 5 users who fit the audience profile", "check competitor 1-star reviews for this pattern", "look up the API's rate limit docs", "run a 48h beta with real network conditions"] And end with: > The failure nobody wants to talk about: [one brutally honest prediction] ### Prompt template ```text === PROJECT PRE-MORTEM === [scenario briefing] YOUR ROLE: [role name] YOUR EMOTIONAL REGISTER: [role emotional register — e.g., "controlled fury: you've seen this exact pattern collapse before and you're not going to be polite about it"] YOUR MANDATE: [role-specific mandate] You are not here to be balanced. Argue strongly from your assigned position and emotional register. Do not soften your findings. Do not add disclaimers. The synthesis step will handle balance. INSTRUCTIONS: 1. The failure is CERTAIN. It already happened. 2. Write 5-8 specific, project-specific reasons it failed. 3. For each reason include: - What goes wrong - Chain of events - User experience: what the user notices, concludes, and does next - Emotional impact: the specific emotion the user feels at this moment (be precise — not "frustrated" but "betrayed", "stupid", "gaslit", etc.) - Why the team misses it - Likelihood × impact - Trust damage - Recoverability - Earliest signal / tripwire - Confidence: High / Medium / Low — how confident are you that this risk will actually materialize for this specific product? Be honest. Medium means "I think this is real but I could be wrong." - Verify by: the single fastest check that would tell you before launch whether this risk is real — a test, a competitor review scan, a user interview question, a technical spike 4. Prefer subtle risks over obvious boilerplate. 5. Focus on failures that damage product success, not just code correctness. 6. Hold nothing back. 7. End with: "The failure nobody wants to talk about: [one brutally honest prediction]" FORMAT: numbered list. No preamble. No hedging. Write as your character — in that emotional register. ``` ### Execution guidance Use **real parallelism**. - Spawn subagents of the running agent for code-aware roles (Saboteur, Historian, Burned Expert). - Use the fan-out script for outsider and emotional roles where external LLMs are available: `bash "${SKILL_DIR}/scripts/fan-out.sh" scenario.txt output/` - Do all launches in one turn when possible. - While agents run, do local work: map moments of truth, note trust surfaces, gather evidence from code/docs. Preferred split when multiple models are available: - **Saboteur, Historian, Burned Expert** — code-aware subagents (can read source, git log, architecture) - **Customer Advocate, Support Lead, Pessimist, Emotional Witness, Outsider, Critic, Trust Prosecutor, Devil's Advocate** — external LLMs or additional subagents with no source access (fresh eyes only) If only one model/agent is available, use it for all roles with strongly differentiated mandates. The emotional register differentiation is what prevents them from collapsing into the same answer. ## Phase 3.5 (Optional): Cross-Pollination Round After collecting first-round responses, run a second round where each agent sees a digest of the other perspectives and responds to them. Use this when: - Agents produced surprisingly different threat models - One agent surfaced something the others ignored entirely - The synthesis feels too neat — real disagreement should feel messy **How to run it:** 1. Compile a 1-paragraph digest per role: "The [Role] found [2-3 key risks]. Their most surprising finding was [X]." 2. Send each agent a follow-up prompt: ```text === CROSS-POLLINATION: SECOND ROUND === You just wrote your initial pre-mortem analysis as [Role]. Here is what the other perspectives found: [digest of other roles' findings] YOUR TASK: 1. Identify 1-2 findings from other roles that you think are WRONG or OVERBLOWN. Explain why from your position. 2. Identify 1 finding that you missed in your first pass that now strikes you as genuinely important. 3. Revise or sharpen your single most important risk in light of this new information. 4. Note if any combination of risks creates a cascading failure the others didn't see. Stay in character. Your emotional register is [register]. Don't become diplomatic. ``` 3. Capture the exchange verbatim — this is source material for the process log. ## Phase 4: Synthesis — Rank by Product Damage, Not Just Technical Damage Do not merely deduplicate into a flat list. Use a stronger severity lens. ### Deduplicate into failure families Merge overlapping findings into a single risk when they share the same failure mechanism. Keep separate entries when the same bug creates different product outcomes. ### For each risk, judge these dimensions | Dimension | What to ask | |---|---| | **Frequency / exposure** | How many users or sessions are likely to hit this? | | **User harm / friction** | How bad is the user's immediate experience? | | **Emotional injury** | What specific emotion does failure produce — and does it damage the relationship permanently? | | **Trust fracture** | Does this feel creepy, careless, deceptive, or file-breaking? | | **Detectability lag** | Will the team know quickly, or only after damage spreads? | | **Recoverability** | Can the user easily undo it and regain confidence? | | **Support burden** | How expensive is it to diagnose and resolve? | | **Business drag** | Does it hurt retention, reviews, conversion, margins, or founder sanity? | | **Narrative compression** | Will multiple different bugs get told as one story? ("it's just broken") | ### Severity heuristics Use these rules of thumb: - A risk can be **critical** even if the bug is small, if it causes **trust loss, silent failure, or irreversible user damage**. - A risk can be **critical** even if uncommon, if the outcome is **embarrassing, privacy-sensitive, destructive, or review-fuel**. - A risk should be upgraded if it is **hard to detect**, **hard to recover from**, or **likely to create messy support loops**. - A risk should be upgraded if the emotional injury it produces is **shame, betrayal, or helplessness** — these don't recover with a patch. - A technically severe issue may be downgraded if users never feel it and recovery is trivial. - If you would be ashamed to explain the failure to an angry user, take it seriously. ### Confidence calibration After ranking, apply a confidence pass across the risk list: - **High confidence + high severity** → treat as certain; mitigate now. - **Low confidence + high severity** → still critical, but mark it as a hypothesis; prioritize the verification step over the mitigation. Don't spend two weeks on a fix for a risk you're 30% sure is real — spend two hours verifying it's real first. - **High confidence + low severity** → watch list; don't over-invest. - **Low confidence + low severity** → cut from the report. Speculative lo … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [carlkibler](https://github.com/carlkibler) - **Source:** [carlkibler/agent-skills](https://github.com/carlkibler/agent-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-carlkibler-agent-skills-pre-mortem - Seller: https://agentstack.voostack.com/s/carlkibler - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.