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.
60
70%
Does it follow best practices?
Impact
—
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 SRE-focused niche with an explicit 'Use when' clause and good trigger term coverage. Its main weakness is that the 'what' portion could be more specific about concrete actions beyond 'define and implement'—for example, specifying dashboard creation, burn-rate alerting configuration, or error budget policy definition.
Suggestions
Expand the capability list with more concrete actions, e.g., 'create burn-rate alerts, configure monitoring dashboards, define error budget policies' 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 seeking this skill. | 3 / 3 |
Distinctiveness Conflict Risk | The SLI/SLO/error budget/SRE niche is quite specific and unlikely to conflict with other skills. The trigger terms are domain-specific enough to clearly distinguish this from general monitoring or performance skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides highly actionable Prometheus/Grafana configurations for SLO implementation with concrete, executable examples. However, it is significantly verbose with repeated queries, explanations of well-known SRE concepts, and duplicated alert configurations. The lack of a clear end-to-end implementation workflow and missing bundle files for referenced paths weaken its overall effectiveness.
Suggestions
Remove duplicate content: the availability SLI query appears 3+ times and the multi-window burn rate alert section repeats the alerting rules section. Consolidate into a single authoritative location.
Cut explanatory content Claude already knows: the SLI/SLO/SLA hierarchy diagram, 'When to Use' list, 'Choose Appropriate SLOs' considerations, and generic best practices list add little value for an AI assistant.
Add a clear sequential implementation workflow with validation checkpoints, e.g.: 1) Define SLIs → 2) Verify SLI queries return valid data → 3) Set recording rules → 4) Confirm recording rules populate → 5) Configure alerts → 6) Test alert firing.
Either create the referenced bundle files (slo-definitions.md, error-budget.md, slo-template.md) or remove the references to avoid dead links.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Significant verbosity throughout. The SLI/SLO/SLA hierarchy explanation, 'When to Use' bullet list, 'Choose Appropriate SLOs' considerations, and 'Best Practices' numbered list all explain SRE concepts Claude already knows. The same availability SLI query appears at least 3 times (SLI definition, SLO YAML example, and recording rules). The multi-window burn rate alert section duplicates content already shown in the SLO alerting rules section. | 1 / 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 numerical examples, and the SLO definition YAML is directly usable. | 3 / 3 |
Workflow Clarity | While individual components (SLIs, SLOs, recording rules, alerts) are well-defined, there's no clear sequential workflow for implementing SLOs end-to-end. The review process section lists what to check but lacks validation checkpoints—e.g., no step to verify recording rules are producing expected values before setting up alerts, or to validate that SLI queries return sensible results before committing configurations. | 2 / 3 |
Progressive Disclosure | References to external files (references/slo-definitions.md, references/error-budget.md, assets/slo-template.md) are mentioned but no bundle files exist to support them. The main file contains extensive inline content (recording rules, alerting rules, dashboard structure) that could be split into referenced files, while the overview itself is quite long. | 2 / 3 |
Total | 8 / 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.
5a13356
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.