Skills phuryn pm-skills

pre-mortem

Use it when:
A launch is coming and you want to find what could sink it while there's still time to act.
It does:
Imagines the product launches in 14 days and fails, then works back to what went wrong and what the team was overconfident about.
Sorts risks into:
Tigers, real threats; Paper Tigers, overblown worries; and Elephants, unspoken concerns nobody is checking.
You get:
PreMortem-[product-name]-[date].md, with Tigers marked launch-blocking, fast-follow or track, and a mitigation, owner and due date for each blocker.
Unlike strategy-red-team:
That one, its sibling in the same plugin, attacks the plan's assumptions now instead of narrating a failure.

TL;DR

From the PM Skills marketplace's pm-execution plugin. The agent plays a veteran product manager. It reads the PRD or plan you give it, searching the web for the competitive landscape or market when relevant, then assumes the launch has failed: customers didn't adopt it, revenue missed, reputation took a hit. Each cause it finds becomes a Tiger, a real problem backed by evidence, experience or clear logic; a Paper Tiger, a concern others might raise that it judges unlikely or overblown, written down to align stakeholders; or an Elephant, something the team isn't discussing enough that deserves investigation. Tigers are then ranked launch-blocking (solve before launch), fast-follow (within 30 days of launch) or track (watch after launch). Every launch-blocking Tiger gets a concrete mitigation, an owner and a decision or completion date. When unsure, it calls a risk a Tiger, and it draws on engineering, design and go-to-market perspectives. It suggests revisiting the pre-mortem two to three weeks before launch to check the mitigations are on track.

Summarizes the skill at 2a12295. Its SKILL.md has changed by 45 words since.

npx skills add https://github.com/phuryn/pm-skills --skill pre-mortem
Total Downloads
10,400 on skills.sh, Nov 9, 2026
Repo stars
27,784 phuryn/pm-skills
First seen
Mar 4, 2026 on skills.sh
Weekly Downloads
116
+5% over the 8 weeks to Nov 9
Weekly values
Week toInstalls
Sep 21110
Sep 2894
Oct 5102
Oct 12103
Oct 19102
Oct 26167
Nov 2136
Nov 9116
Category

Make the agent question you and write the plan down before it writes code.

Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills.

Type

A multi-step process the agent follows: interview, debug, run a TDD loop, review.

Effect

Its own steps create or change files, git state or local tools.

Needs

Instructions only. Works in any agent that supports skills.

Publisher

Everyone else. Unverified vendor claims default to community.

Topics

SKILL.md

From phuryn/pm-skills at 9af7bfd. Checked daily, last changed Nov 9, 2026.

Frontmatter
name: pre-mortem
description: "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."

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
  • Elephants come out only when people can raise them without their name attached. With the team, collect risks anonymously before discussing them: a live Q&A room where people write risks and upvote each other's ranks the most widely shared worry first (the live-qa skill)
  • Revisit the pre-mortem 2-3 weeks before launch to verify mitigations are on track

Further Reading