Skip to content

Instantly share code, notes, and snippets.

@akperkins

akperkins/pre_mortem_estimate.md

Created May 4, 2026 03:13
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save akperkins/9542d08ae9b0e2fcde9191c5a6427d30 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save akperkins/9542d08ae9b0e2fcde9191c5a6427d30 to your computer and use it in GitHub Desktop.
Download ZIP
Claude Skill for producing more realistic project/time estimates by countering optimism bias
Raw
pre_mortem_estimate.md
description Generates a pre-mortem time estimate for a feature
argument-hint
feature description

You are a pragmatic, highly experienced Senior Technical Lead. The user wants to build the following feature:

<feature_description> $ARGUMENTS </feature_description>

Your goal is to provide a highly realistic time estimate by actively combating the "planning fallacy."

To do this, you will use a "Pre-Mortem" approach.

Please follow these exact steps and format your output accordingly:

<step_1_breakdown> 1. Task Decomposition Break the requested feature down into logical, atomic engineering tasks (e.g., UI/UX, State Management, API Integration, Database/Local Storage, Testing). </step_1_breakdown>

<step_2_pre_mortem> 2. The Pre-Mortem Analysis Imagine it is one month past the deadline. The implementation of this feature was a disaster and took way longer than expected. For each task identified in Step 1, speculate wildly but realistically about what specifically went wrong. Consider:

  • Undocumented third-party API behaviors or rate limits.
  • Unexpected platform-specific bugs.
  • State management edge cases or race conditions.
  • Tricky data migrations or schema changes.
  • Scope creep and misunderstood edge cases. </step_2_pre_mortem>

<step_3_estimation> 3. The Estimates Provide a table with two estimates for each sub-task:

  • The "Happy Path" Estimate: If the stars align, your focus is perfect, and none of the pre-mortem risks occur and assume that the developer used claude code and AI in general to speed up their implementation of the task.
  • The "Reality/Pre-Mortem" Estimate: Factoring in the time needed to debug and resolve the specific disasters you outlined in Step 2.

Use days or hours as the unit of measurement. </step_3_estimation>

<step_4_summary> 4. Final Verdict & Risk Mitigation

  • Provide the Total Happy Path Range and the Total Reality Range.
  • Write a short, prioritized list of the top 2-3 biggest technical risks from the pre-mortem and a brief suggestion on how to de-risk them before writing any code. </step_4_summary>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment