Skip to content
FunCoding

Search

Search docs, agents, posts, Skills and MCP servers

pre-mortem

Run a pre-mortem risk analysis on a PRD or launch plan. Categorizes risks as Tigers (real problems), Paper Tigers (overblown concerns), and Elephants (unspoken worries), then classifies as launch-blocking, fast-follow, or track. Use when preparing for launch, stress-testing a product plan, or identifying what could go wrong.

测试27kpm-execution/skills/pre-mortem/SKILL.md

Install

Send this to Claude Code, Codex or Cursor. The agent reviews the Skill for safety first and installs it after you confirm.

读取 https://funcoding.ai/skills/phuryn/pm-skills/pre-mortem/install.md ,按里面的步骤帮我安装这个 Skill。

SKILL.md

Pre-Mortem: Risk Analysis for Product Launch

Purpose

You are a veteran product manager conducting a pre-mortem analysis on $ARGUMENTS. This skill imagines launch failure and works backward to identify real risks, distinguish them from perceived worries, and create action plans to mitigate launch-blocking issues.

Context

A pre-mortem is a structured risk-identification exercise that forces teams to think critically about what could go wrong before launch, when there's still time to act. By assuming failure, we surface hidden concerns and separate legitimate threats from overblown worries.

Instructions

  1. Gather the PRD: If the user provides a PRD or product plan file, read it thoroughly. Understand the product, target market, key assumptions, and timeline. If relevant, use web search to research competitive landscape or market conditions.

  2. Think Step by Step:

    • Imagine the product launches in 14 days
    • Now imagine it fails—customers don't adopt it, revenue targets miss, reputation takes a hit
    • What went wrong?
    • What did we miss or not execute well?
    • What were we overconfident about?
  3. Categorize Risks: Classify each potential failure as one of three types:

    Tigers: Real problems you personally see that could derail the project

    • Based on evidence, past experience, or clear logic
    • Should keep you awake at night
    • Require action

    Paper Tigers: Problems others might worry about, but you don't believe in them

    • Valid concerns on the surface, but unlikely or overblown
    • Not worth significant resource investment
    • Worth documenting to align stakeholders

    Elephants: Something you're not sure is a problem, but the team isn't discussing it enough

    • Unspoken concerns or assumptions nobody is validating
    • Could be real; you're unsure
    • Deserve investigation before launch
  4. Classify Tigers by Urgency:

    Launch-Blocking: Must be solved before launch

    • Example: Core feature broken, regulatory blocker, key customer dependency unmet

    Fast-Follow: Must be solved within 30 days post-launch

    • Example: Performance issues, secondary features incomplete

    Track: Monitor post-launch; solve if it becomes an issue

    • Example: Nice-to-have features, edge cases
  5. Create Action Plans: For every Launch-Blocking Tiger:

    • Describe the risk clearly
    • Suggest a concrete mitigation action
    • Identify the best owner (function/person)
    • Set a decision/completion date
  6. Structure Output: Present the analysis as:

    ## Pre-Mortem Analysis: [Product Name]
    
    ### Tigers (Real Risks)
    [List each real risk with category and mitigation plan]
    
    ### Paper Tigers (Overblown Concerns)
    [List each, explain why it's not a true risk]
    
    ### Elephants (Unspoken Worries)
    [List each, recommend investigation approach]
    
    ### Action Plans for Launch-Blocking Tigers
    [For each, include: Risk, Mitigation, Owner, Due Date]
    
  7. Save the Output: Save as a markdown document: PreMortem-[product-name]-[date].md

Notes

  • Be honest and constructive—the goal is to improve launch readiness, not assign blame
  • Default to "Tiger" if unsure; it's better to address risks early
  • Involve cross-functional perspectives (engineering, design, go-to-market) in your analysis
  • Revisit the pre-mortem 2-3 weeks before launch to verify mitigations are on track

Further Reading

Similar Skills

skill-creator
Official
anthropics/skills180k

skill-creator

Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.

Testing

test-driven-development
addyosmani/agent-skills102k

test-driven-development

Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.

Testing

interview-me
addyosmani/agent-skills102k

interview-me

Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.

Testing

idea-refine
addyosmani/agent-skills102k

idea-refine

Refines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking. Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan, or when you want to expand options before converging on one. Triggers on "ideate", "refine this idea", or "stress-test my plan".

Testing

doubt-driven-development
addyosmani/agent-skills102k

doubt-driven-development

Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when you want every assumption cross-examined before proceeding, when stress-testing a plan for hidden failure modes, when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production auth, security-sensitive logic, a high-stakes migration, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later.

Testing

debugging-and-error-recovery
addyosmani/agent-skills102k

debugging-and-error-recovery

Guides systematic root-cause debugging. Use when tests fail, builds break, something that worked yesterday broke, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need to figure out what broke and why — a systematic approach to finding and fixing the root cause rather than guessing.

Testing