just-vibeDecisions · plan by default
/decision-premortem
Assume a proposal failed and identify plausible causes
Use to analyze plausible future failure of a proposal; challenge tests its current assumptions and ops-postmortem reconstructs an actual incident.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select decision-premortem from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv decision-premortem, /just-vibe decision-premortem and /jv:decision-premortem in Claude. See shortcut setup and context examples.
/just-vibe:decision-premortem Identify plausible ways the migration plan could fail and early warning signs./just-vibe:decision-premortem Premortem a rollout whose rollback cannot undo generated data./just-vibe:decision-premortem Analyze hypothetical failure without treating it as an observed incident.What the agent does
- Assume a concrete failed outcome and work backward through design choices and contributing conditions to realistic causal chains.
- Rank the chains by impact and likelihood, identify an observable early warning signal for each, and propose proportionate mitigations.
Inputs
- proposal, success definition, operating context, and time horizon.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Plausible reasons the proposal could fail and preventive actions.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Plan; proposal, success definition, operating context, and time horizon.
- Prerequisites
- The decision question, constraints, alternatives or permission to identify them, and relevant project evidence. Current vendor claims and prices require current authoritative sources during execution. Scores are decision aids, not facts.
Expected output
- Failure chains with early signal, mitigation, response and residual uncertainty, plus untested assumptions.
How the work is checked
- Risks connect to specific proposal choices; a mitigation includes a detectable signal or concrete action.
When to stop or clarify
- Do not present hypothetical failures as observed incidents or pad the report with generic catastrophes unrelated to the design.
Handling missing context
- Infer
- Recover hard constraints, the current option, adoption status and stated priorities from the brief and prior decisions.
- Assume
- State the failure definition and time horizon as assumptions before listing causes.
- Ask
- Ask only about a missing constraint or preference that could reverse the recommendation; do not demand a complete scoring questionnaire.
Technical guidance
- Evidence
- Inspect dependency assumptions, operational ownership, adoption constraints and failure recovery.
- Method
- Build a plausible trigger-to-impact chain for each material failure, then identify an early signal and an intervention that breaks that chain.
- Pitfall
- Generic risks with no mechanism or observable warning cannot guide implementation.
- Check
- Test whether each mitigation addresses its stated mechanism and whether a responder could detect the signal in time.
Situational decisions
When a risk cannot be connected to this proposal: Remove the generic warning and focus on mechanisms supported by context.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.