Lean tables and copy-paste command blocks with no padding; the single one-line SLO definition establishes domain-specific terms (request- vs window-based) Claude would not already know, so every token earns its place.

Provides fully executable commands and pipelines such as 'cx slos list -o json | jq [...]', 'cx slos get <id> -o json', and 'cx slos create --from-file slo.json --yes' that are copy-paste ready, not pseudocode.

The round-trip authoring flow (get -> edit -> create) is sequenced and guardrails like --yes and affected-alert review are noted, but for destructive write operations (create/update/delete) there is no explicit validate-or-preview-before-apply checkpoint, so verification remains implicit.

A compact, self-contained skill with no bundle files, organized under clear sections (CLI Commands, SLO Definition, Monitoring SLO Health, Creating/Updating, Key Principles, Related Skills); the only links point to sibling skills, not nested bundle references.

Lists multiple concrete actions — 'list and inspect SLOs', 'check whether targets and error budgets are healthy', 'create, update, or delete SLO definitions from JSON' — matching the comprehensive concrete-actions anchor rather than the partial score-2 anchor.

Explicitly states both what it does (manage/list/inspect/check/create/update/delete SLO definitions) and when to use it via an explicit 'Use when...' clause with triggers, so the when-guidance is stated rather than merely implied.

Cites natural user phrases like 'list SLOs', 'check SLO status', 'is an SLO breaching', 'error budget', 'create/update/delete an SLO', and 'service level objective', giving broad coverage of terms users would actually say.

Scoped to a named Coralogix CLI ('cx slos') with a clear SLO-management niche and distinct triggers, unlikely to overlap with sibling skills such as alerts or telemetry querying.