mcpField
S
service-level-slo-review

service-level-slo-review

github.com/sylphxaiCloud & DevOps141 installsUpdated today
Repository

About service-level-slo-review

A skill for turning service-level questions into an actionable SLO plan, with metrics, owners, decision gates, and recovery paths. It is intended for teams reviewing reliability targets and customer promises.

Key features

  1. 01Maps critical journeys and risks
  2. 02Separates SLOs, SLAs, and targets
  3. 03Defines SLIs and error budgets
  4. 04Plans alerts and customer communications
  5. 05Produces checklists and decision artifacts

Use cases

  1. 01Reviewing service reliability commitments
  2. 02Setting latency and freshness objectives
  3. 03Planning error-budget alerts and responses

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/sylphxai/skills --skill service-level-slo-review

After installing, type/service-level-slo-reviewin Claude Code to confirm it loaded.

Bundled filesagents/openai.yamlreferences/service-level-slo-patterns.md

Details

From the project README

Service Level SLO Review

Use this skill to convert a SLOs, SLIs, SLAs, error budgets, uptime, latency, freshness, recovery objectives, and customer reliability promises question into a concrete artifact with owners, gates, metrics, and recovery paths.

Workflow

  1. Identify critical user journeys, customers, contractual promises, measurement sources, failure modes, support commitments, and business risk.
  2. Read references/service-level-slo-patterns.md.
  3. Separate internal SLO, external SLA, support target, uptime claim, freshness objective, latency objective, and recovery objective.
  4. Define SLIs, windows, exclusions, error budget policy, alerting, status page behavior, maintenance windows, and customer communications.
  5. Produce service-level plan, state machine, decision table, event schema, reliability checklist, and promise-review cadence.

When not to use

  • Do not use for generic advice the base model already handles without this skill's specific artifact contract.

Guardrails

  • Do not promise an SLA if monitoring, incident response, support process, and credit/remedy policy cannot support it.
  • Do not measure availability only from server uptime when the user journey depends on dependencies, auth, billing, DNS, or queues.
  • Do not hide planned maintenance or partial degradation behind green status.
  • Do not treat SLO burn as an engineering-only metric when customer promises or sales claims are affected.

Output format

Service-level context:
Journey / customer promise / measurement source:

SLO and service-level plan:
| Area | Decision | Evidence | Risk | Owner |
| --- | --- | --- | --- | --- |

SLIs, windows, and promises:
- <item> -> <policy, metric, edge case, support note>

Error budget and communication policy:
- <trigger> -> <action, communication, owner>

Comments

Markdown supported