Use when running a structured operational change or investigation that deserves a paper trail - a production change, multi-step troubleshooting, a migration/upgrade, or a recurring routine op. Drives a Plan→RootCause→…
---
name: ops-session
description: Use when running a structured operational change or investigation that deserves a paper trail — a production change, multi-step troubleshooting, a migration/upgrade, or a recurring routine op. Drives a Plan→RootCause→Action→Verify→Learn loop with an anti-hallucination root-cause card (weak evidence hard-blocks writes), autonomy tiers by task kind, evidence-pointer discipline (no bare assertions), and archive + backup + rollback. Not for one-off read-only lookups or a single obvious command.
---
# ops-session
A protocol for running an operational task as a *disciplined session* instead of a
stream of ad-hoc commands. The enemy is the confident wrong move: acting on a
guess, declaring success because a tool printed "ok", or leaving no trail to roll
back or learn from. This skill forces evidence before action, verification after
it, and a durable record either way.
It is **tool-agnostic** — the examples use `kubectl`/`helm`/SQL/HTTP, but the
discipline applies to any system you mutate.
## When to use
- A **production change** (infra, config, schema, traffic, DNS) — anything where a
bad move costs you.
- **Multi-step troubleshooting** where the cause is unclear and you'll mutate state
to fix it.
- A **migration / upgrade / cutover** spanning environments or systems.
- A **recurring routine op** (log sweep, rolling restart, config sync) you want
executed consistently and logged.… install to load the full skill