Define and implement Service Level Indicators (SLIs) and Service Level Objectives (SLOs) with error budgets and alerting. Use when establishing reliability targets, implementing SRE practices, or measuring service performance.
82
77%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./tests/ext_conformance/artifacts/agents-wshobson/observability-monitoring/skills/slo-implementation/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description that clearly identifies its niche in SRE reliability engineering with good trigger terms and an explicit 'Use when' clause. Its main weakness is that the capability listing could be more granular—specifying concrete deliverables like burn-rate alerts, SLO dashboards, or error budget policies would strengthen it further.
Suggestions
Expand the 'what' portion with more concrete actions, e.g., 'create burn-rate alerts, configure SLO dashboards, calculate error budget consumption' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (SLIs, SLOs, error budgets, alerting) and some actions ('define and implement'), but doesn't list multiple concrete actions in detail—e.g., it doesn't specify what 'implement' entails (dashboards, monitoring configs, burn-rate alerts, etc.). | 2 / 3 |
Completeness | Clearly answers both 'what' (define and implement SLIs/SLOs with error budgets and alerting) and 'when' (explicit 'Use when' clause covering reliability targets, SRE practices, and measuring service performance). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'SLIs', 'SLOs', 'error budgets', 'alerting', 'reliability targets', 'SRE practices', 'service performance'. These cover the main terms a user would naturally use when requesting this kind of work. | 3 / 3 |
Distinctiveness Conflict Risk | The SLI/SLO/error budget domain is a clear niche within SRE. The specific terminology (SLIs, SLOs, error budgets) makes it highly unlikely to conflict with general monitoring, alerting, or performance skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides strong, actionable Prometheus/Grafana configurations for SLO implementation with concrete, executable examples. However, it suffers from verbosity in explaining well-known SRE concepts, lacks a clear implementation workflow with validation steps, and has some content duplication (burn rate alerts appear twice). Trimming the conceptual explanations and adding an explicit implementation sequence would significantly improve it.
Suggestions
Remove or drastically shorten the SLI/SLO/SLA hierarchy, 'Purpose', 'When to Use', and generic 'Best Practices' sections—Claude already knows these SRE concepts.
Add an explicit implementation workflow with validation checkpoints, e.g.: 1) Define SLIs → 2) Create recording rules → 3) Verify with `promtool check rules` → 4) Deploy and validate metrics appear → 5) Add alerting rules → 6) Test alerts with `amtool`.
Remove the duplicated multi-window burn rate section that repeats content already in the SLO Alerting Rules section.
Move the detailed Prometheus recording rules and alerting configurations to a referenced file, keeping only a concise example in the main skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains some unnecessary padding like the 'Purpose' and 'When to Use' sections that restate the obvious, the SLI/SLO/SLA hierarchy diagram explaining well-known concepts, and the 'Best Practices' list of generic advice. The core Prometheus recording rules and alerting configs are valuable, but the surrounding content could be significantly tightened. | 2 / 3 |
Actionability | The skill provides fully executable PromQL queries, complete Prometheus recording rules, and concrete alerting rule YAML configurations that are copy-paste ready. The error budget calculations include specific numeric examples, and the SLO definition YAML is directly usable. | 3 / 3 |
Workflow Clarity | While the content covers the components well (SLIs → SLOs → error budgets → alerts → dashboards), there's no explicit step-by-step implementation workflow with validation checkpoints. The review process section lists what to check but not how to verify correctness of the implementation. For a skill involving production alerting configuration, missing validation steps (e.g., testing alert rules, verifying recording rules produce expected values) is a gap. | 2 / 3 |
Progressive Disclosure | References to external files exist (slo-definitions.md, error-budget.md, slo-template.md) and related skills are listed, but the main file is quite long with inline content that could be split out (e.g., the full alerting rules, dashboard queries). The multi-window burn rate section largely duplicates the alerting rules section above it. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
47823e3
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.