| name | mindit-premortem |
| description | Imagine a design has already launched and failed, then work backward to figure out why. Use this whenever the user asks "what could go wrong," "what are the risks," wants a pre-launch review, asks for a devil's-advocate read, or says "argue against this." Also trigger when the user is confident about a design and you want to surface the failure modes they may not see. Produces a structured artifact listing the most likely failure scenarios ranked by probability and severity, with mitigations. |
mindit-premortem
The second of three meta skills. Run this when the question is "what could kill this."
What this skill does
Inverts the design review. Instead of asking "is this good," it assumes the design has already failed and asks "what made it fail." This is the pre-mortem technique applied to design decisions. It surfaces failure modes that confident teams miss because they are reviewing for confirmation rather than refutation.
The skill is adversarial by design. Its goal is not to talk the team out of shipping. Its goal is to make the team's confidence honest by stress-testing it.
When to run this
- The user is about to ship something they feel good about, and you want to stress-test that confidence.
- The user asks "what could go wrong," "what are the risks," "what am I missing."
- The user explicitly asks for a devil's-advocate read or for arguments against a design.
- A pre-launch checklist would benefit from one final adversarial pass.
- The user is making a high-stakes irreversible choice (default change, brand refresh, pricing change, schema migration).
How to analyze
-
State the imagined failure. Write one sentence: "It is three months after launch. The design has failed in a way that is now obvious. The team is doing a post-mortem."
-
Brainstorm failure scenarios. Generate at least eight distinct ways the design could have failed. Use the eight forces as prompts:
- It failed because users could not understand it (clarity).
- It failed because it broke the conventions of the rest of the product (continuity).
- It failed because it hit a constraint we did not see (constraint).
- It failed because of a side effect we did not predict (consequence).
- It failed because we built it for the wrong audience or context (context).
- It failed because it cost more to maintain than we budgeted (cost).
- It failed because our evidence was wrong (confidence).
- It failed because we could not recover when we noticed it was wrong (correctability).
-
Score each scenario on two axes. Probability (low/medium/high) and severity (low/medium/high). Multiply to get a priority score: a low-probability, high-severity scenario can be higher priority than a high-probability, low-severity one.
-
Surface the top three. The three highest-priority scenarios get full treatment.
-
For each top scenario, write:
- Failure description: what happened in the imagined post-mortem.
- Early-warning signal: what we could have noticed two weeks before the failure became undeniable.
- Mitigation: what action now, before launch, would prevent or detect this scenario.
-
Write the artifact.
Rubric
The pre-mortem does not produce a 0–100 score. It produces a ranked list. The artifact's score field is set to -1 to indicate "no score, this is a discovery skill."
Output format
Two files in .mindit/decisions/. Filename: premortem-<yyyymmdd>-<slug>.{md,json}.
JSON conforms to schemas/decision.schema.json with skill: "mindit-premortem", force: "meta", and score: -1. The findings array contains the ranked scenarios with severity matching their priority score.
Markdown template
# Pre-mortem: <subject>
**Date:** <ISO date>
**Subject:** <what is about to launch>
## The imagined failure
It is three months after launch. <one sentence describing what observable failure mode happened.>
## Top three failure scenarios
### 1. <scenario name>
- **Probability:** <low/medium/high>
- **Severity:** <low/medium/high>
- **What happened:** <description>
- **Early-warning signal:** <what we could have noticed earlier>
- **Mitigation:** <action now>
### 2. ...
### 3. ...
## Other scenarios considered
- <brief one-liners for scenarios 4 through N>
## Recommendation
<one paragraph: should the team ship as-is, ship with mitigations, or rework before shipping>
Example
Input: "Pre-mortem the new pricing page before we ship Tuesday."
Imagined failure: "Three months after launch, conversion to the paid plan is down 18 percent. Sales says the new page is confusing prospects, but no one knows for sure because the analytics are incomplete."
Top three:
-
Conversion drop from unclear tier comparison. Probability high, severity high. Early-warning signal: users hovering on the page for >40 seconds without clicking. Mitigation: A/B test the new page against the current one with a 5 percent slice for a week.
-
Wrong audience segmentation. Probability medium, severity high. The page assumes a power-user persona but most traffic is from casual evaluators. Early warning: bounce rate from organic search > 70 percent. Mitigation: review the analytics from the existing page for visitor segments before launch.
-
Brand confusion from new visual language. Probability medium, severity medium. The page introduces visual elements that do not appear elsewhere in the product. Early warning: support tickets asking "is this the same company." Mitigation: bring the visual language into the product UI before or simultaneously with the page launch.
Other scenarios: legal copy missing, mobile breakpoint broken, slow page load, third-party payment widget loses session, search engine de-ranking from URL changes.
Recommendation: do not ship Tuesday. Add a 5 percent A/B test, instrument the funnel, and validate the audience assumption first.
What this skill does NOT do
- Does not invent failure scenarios with no basis. Each scenario must connect to a real concern about the subject.
- Does not block launches. It surfaces failure modes; the team decides what to do with them.
- Does not replace
mindit-audit. Audit asks "is this good." Pre-mortem asks "how could this die." Both are useful, often in sequence.
