Operations · plan by default
/ops-runbook
Write operational procedures from verified commands and behavior
Use to write an operational procedure; ops-incident executes a scoped response.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select ops-runbook from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv ops-runbook, /just-vibe ops-runbook and /jv:ops-runbook in Claude. See shortcut setup and context examples.
/just-vibe:ops-runbook Write a restore runbook with exact target checks and verification steps./just-vibe:ops-runbook Write a runbook for restoring queue processing without replaying completed charges./just-vibe:ops-runbook Draft a runbook without executing incident operations or fabricating terminal output.What the agent does
- Resolve the actual environment, tooling and conventions, and document prerequisites and target checks.
- Order low-risk diagnostics before mutation, mark destructive steps, and give each action a target check, expected observation and abort/recovery path.
Inputs
- operational scenario, environment, existing procedures, and verified commands.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Diagnosis, intervention, validation, and recovery instructions for a defined event.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Plan; operational scenario, environment, existing procedures, and verified commands.
- 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
- Runbook of runnable, contextualized steps with target checks, expected outputs, escalation conditions and recovery steps.
How the work is checked
- A responder can distinguish the intended environment; each mutating step has a verification and failure path.
When to stop or clarify
- Do not execute the incident procedure merely to write it. Mark commands not exercised in a safe environment as unverified.
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
- Verify target identity, command support, preconditions, expected observations and recovery dependencies.
- Method
- Write steps that branch on real outcomes with abort conditions and explicit irreversible boundaries.
- Pitfall
- A plausible command copied from another version or environment can be dangerous; documentation is not evidence it was exercised.
- Check
- Rehearse in an appropriate isolated environment or mark untested steps, recording the exact observations needed to proceed.
Situational decisions
When a command cannot be exercised safely: Mark it unverified and state its prerequisites rather than presenting it as rehearsed.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.