/operate

Own what's running — never the code that produced it

Release the product and keep it available, observable, secure, recoverable, and cost-effective — and keep it that way on the night nobody is awake. operate is the only skill in the family whose subject is a running system rather than an artifact: every sibling produces something and hands it on; operate receives an artifact and owns what exists afterwards, indefinitely. It writes infrastructure, pipeline, configuration, policy, and observability code — it does not modify product code to fix a defect it observes; that routes to the owning skill. It may make an emergency change to restore service and must then file it back: stop the bleeding, do not perform the surgery.

The default reader is one person, or a small team, on a managed platform, with no rota. That inverts the published canon deliberately: the SRE canon claims its lessons apply "regardless of size or maturity" while publishing a five-to-eight-person floor in the same chapter, and never resolves the contradiction. Org-scale assumptions — rotas, role separation, change boards — live in surface-org-scale.md and are added, not assumed.

The faceted router

SKILL.md is a router, not a script. Every request selects the smallest sufficient route: one primary job — the twelve below — combined with at most one base surface that reshapes how the job applies to what's actually running, plus the additive org-scale overlay when a rota, role separation, or formal change approval exist. Read the selected references completely; load two or three at most, never the whole pack.

The twelve primary jobs

Each job is one reference, read fully only when its route is selected. Jobs 10–12 — decommissioning, dependency-lifecycle, and the cost-to-serve bridge inside capacity-and-cost — are the three facets the research found grep-verified absent from competitor ops content; this is the whole surface, not a headline slice.

Full router table & invariants: SKILL.md.

Six surfaces + one additive overlay

One base surface, at most, reshapes every job for what's actually running — the same rollout job is bounded differently on a managed platform than on a mobile app that can only roll forward. The org-scale overlay is additive — it stacks on top of whichever base you picked, never replaces it — and carries a distinct violet identity throughout this page, the same convention quality uses for its own regulated overlay.

Release & rollout — the flagship

Most treatments of a rollout stop at "it went out clean." The pack's sharpest synthesis is that a rollout result is evidence with a class and a population — a canary tells you something true and specific about the cohort it reached, and something much weaker, or nothing, about everyone else. Confusing the two is how a clean canary precedes a failed rollout.

The load-bearing table — a clean result from each mechanism earns evidence of a specific class and scope, never a blanket "it works":

Solo default — no rota watching the canary: automated abort on the pre-registered threshold, not a person deciding in the moment · longer bake time before widening the ring · a smaller default blast radius · a kill switch tested before you need it. The roles do not disappear at n=1 (I13) — substitute mechanism for headcount.

What makes this different

Two stances set operate apart from the technique libraries it sits beside: it writes the solo/small-team case as the default rather than an afterthought, and it subtracts the folk number everywhere the field cites a round threshold with no published rationale.

The universal invariants

References cite these by number; the numbering is canonical. These rules govern every route, whichever files it loads.

• I1 — Deploy≠release≠launchSeparate them, or you cannot roll back, dark-launch, or gate.
• I2 — Evidence has a class and a populationA canary is observed for its cohort, inferred for everyone else. Never extend it past its conditions.
• I3 — Abort criteria fixed before exposureDeriving them while watching a graph is the peeking problem — it inflates error rates like p-hacking does.
• I4 — Page only on user-visible harmAlerts under ~50% accuracy are broken. A slow burn earns a ticket, never a page.
• I5 — A recovery objective covers one failure modeThe failure that hurts you is the one outside the envelope it was designed against.
• I6 — You have restore drills, not backupsAn untested backup is an assumption wearing a backup's clothes.
• I7 — Cost is an availability controlMeasure cost-to-serve per unit of value; cap anything whose spend scales with activity, not users.
• I8 — Pin anything that can change under youA dependency can be swapped, not just withdrawn — with no deploy, no diff, no audit trail.
• I9 — Check licence and livenessA metadata field, a README-only grant, an undisclosed derivative, an archived-but-correct project are four distinct traps.
• I10 — Stop the bleeding, don't do the surgeryEmergency restoration is operate's; the fix routes back with a filed defect.
• I11 — CI is productionA runner holding deploy credentials is among the most privileged machines you own.
• I12 — Halt is not the same authority as claimA clean rollout licenses continuing. It never licenses telling a customer the product is conformant.
• I13 — Roles don't disappear at n=1Only the people do. The scribe function vanishes first, and the postmortem depends on it.
• I14 — Subtract the folk number, name the interestCite provenance or do not cite — including when the party stating a number sells the thing it measures, which sometimes makes the claim stronger.

What a pass produces

operate's core workflow runs against whatever upstream artifacts exist — a quality ship decision, an architecture SLO target, a build skill's handoff — and says so explicitly when none were supplied, rather than inventing one.

The handoff seams

operate consumes upstream artifacts without silently overriding them — the ship/claim decision and residual-risk register from quality, SLO targets from architecture, a handoff from whichever build skill produced the artifact — and says so explicitly when none exist, rather than inventing a target or a decision to fill the gap. It is rarely terminal: it emits a compact handoff.yaml beside the deploy record whenever downstream work is expected.

release_id: <identifier>
deploy_release_launch: [deployed_at,
  released_at, launched_at]
rollout.result: evidence_class + scope
residual_risk: [inherited_from_quality,
  newly_surfaced] — owner + expiry
emergency_fixes_filed: [routes_to, change]
volatile_facts: [fact, value_at_handoff,
  reverify]

Most solo, single-skill deploys need no handoff.yaml at all. When nothing downstream will read it, skip the companion and keep the rollout record in the deploy log instead. When one is written, only deploy_release_launch.deployed_at is required; the other two timestamps may be explicit "not yet" or "not this skill's call." Never silently invoke a sibling skill — name it in recommended_next.

Start here

Install once. It's a plain SKILL.md router — no flags, no config, no scripts — so it activates on natural-language phrasing ("can we widen this rollout," "what's our real RTO for this database," "page just fired at 3am, is it real," "what's this actually costing per tenant") rather than a fixed command.

The same install runs on any Agent Skills host. Codex installs to ${CODEX_HOME:-$HOME/.codex}/skills and triggers with $operate; agents remains a separate cross-agent installation target.