| name | premortem |
| description | Analyze what could go wrong with a plan. Use when:
- User asks "what could go wrong", "risks", "potential issues"
- Before implementing a significant change
- User wants to validate an approach
- Planning a risky operation
|
| context | fork |
| agent | oracle |
Premortem Analysis
Analyze potential failure modes before they happen.
Purpose
Imagine the project has failed. What went wrong?
This technique surfaces risks that optimism bias might hide.
Analysis Framework
1. Technical Risks
- What could break?
- What dependencies might fail?
- What edge cases are unhandled?
- What performance issues might emerge?
2. Integration Risks
- How might this affect other parts of the system?
- What backwards compatibility issues exist?
- What migration challenges are there?
3. Operational Risks
- What could go wrong in production?
- What monitoring is missing?
- What recovery procedures are needed?
4. User Experience Risks
- How might users misuse this?
- What accessibility issues exist?
- What confusion might arise?
Output Format
## Premortem: [Feature/Change]
### High Risk
- [Critical failure mode]
→ Mitigation: [How to prevent]
### Medium Risk
- [Significant issue]
→ Mitigation: [How to address]
### Low Risk
- [Minor concern]
→ Mitigation: [Simple fix]
### Recommendations
1. [Priority action]
2. [Secondary action]
3. [Nice to have]
When to Run
- Before large refactoring
- Before deploying new features
- Before architectural changes
- When something feels risky
Remember
- Be genuinely pessimistic
- Consider non-obvious failure modes
- Propose concrete mitigations
- Store risks as learnings for future reference
