slo-implementation
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.
65
77%
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
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 PromQL queries and YAML configs. However, it's somewhat verbose with explanatory content Claude doesn't need (SLI/SLO/SLA hierarchy, generic best practices), lacks a clear implementation workflow with validation steps, and references bundle files that don't exist.
Suggestions
Remove or drastically shorten the SLI/SLO/SLA hierarchy explanation, 'Purpose', 'When to Use', and generic best practices sections — Claude already understands these concepts.
Add an explicit implementation workflow with numbered steps and validation checkpoints (e.g., 'verify recording rules produce expected values before proceeding to alerting rules').
Eliminate the duplicated multi-window burn rate alert section — it repeats content already in the SLO Alerting Rules section.
Either provide 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 | The skill contains some unnecessary content Claude would already know (SLI/SLO/SLA hierarchy explanation, the 'Purpose' and 'When to Use' sections, the best practices list of generic advice like 'align with business goals'). The core Prometheus recording rules and alerting configs are valuable, but the surrounding explanatory text adds bulk without proportional value. | 2 / 3 |
Actionability | The skill provides fully executable PromQL queries, complete Prometheus recording rules, alerting rules with specific burn rate thresholds, and concrete YAML configurations. The error budget formula with worked examples and the SLO definition YAML are copy-paste ready. | 3 / 3 |
Workflow Clarity | While the content covers the components well (define SLIs → set SLOs → calculate error budgets → implement recording rules → set up alerts → create 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 itself. | 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 is quite long (~250 lines of content) with sections like the multi-window burn rate alerts duplicating earlier alerting content, suggesting some content could be split out. | 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.
- Repository
- Dicklesworthstone/pi_agent_rust
- Commit
bbc5ade
- Reviewed
Table of Contents
Is this your skill?
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.