just-vibeOperations · plan by default
/ops-postmortem
Produce evidence-based timelines and concrete follow-up work
Use to reconstruct an actual incident; decision-premortem analyzes hypothetical failure.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select ops-postmortem from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv ops-postmortem, /just-vibe ops-postmortem and /jv:ops-postmortem in Claude. See shortcut setup and context examples.
/just-vibe:ops-postmortem Write an evidence-based postmortem without inventing impact counts or owners./just-vibe:ops-postmortem Write a postmortem where deployment timing correlates with failure but causation is unproven./just-vibe:ops-postmortem Draft from partial logs without inventing customers affected, owners or consensus.What the agent does
- Reconcile timestamps, observations and impact evidence.
- Separate the trigger from contributing conditions, and document detection and recovery gaps.
- Tie each preventive or detective action to a documented gap, with a measurable outcome.
Inputs
- incident evidence, timeline, impacts, actions, and intended audience.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Evidence-based learning and follow-up design; no blame assignment or external publication.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Plan; incident evidence, timeline, impacts, actions, and intended audience.
- Prerequisites
- Exact service/environment, time window, revision/configuration identity, authorized logs/metrics, and operational constraints. Prefer observation before intervention; live restarts, traffic changes, restores, and notifications require the requested target/action. Redact sensitive telemetry.
Expected output
- Postmortem with evidence-linked timeline, impact, causal factors, response gaps and measurable follow-up actions.
How the work is checked
- Unknown root cause remains explicit; each proposed action addresses a documented failure mechanism.
When to stop or clarify
- Do not invent owners, impact counts, or consensus. Sending the report or creating external action tickets requires explicit instructions.
Handling missing context
- Infer
- Read service/environment, time window, revision, available telemetry and existing incident or recovery procedure.
- Assume
- Start from supplied logs and read-only observation; rank hypotheses without presenting an unexecuted intervention as recovery.
- Ask
- Resolve the precise target and missing authority before restart, restore, notification or traffic changes; continue evidence analysis while waiting.
Technical guidance
- Evidence
- Collect timestamped events, impact evidence, hypotheses, interventions and unresolved gaps.
- Method
- Separate trigger, contributing conditions and detection/recovery failures; derive follow-ups from demonstrated mechanisms.
- Pitfall
- Invented certainty, blame or assigned owners hides uncertainty and cannot support useful prevention.
- Check
- Link each action to a causal mechanism and observable success condition, preserving unknown impact/root cause where evidence is incomplete.
Situational decisions
When root cause or impact remains unknown: Preserve the uncertainty and propose a discriminating follow-up instead of filling the narrative with guesses.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.