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.
76
70%
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 with explicit 'Use when' triggers and domain-specific terminology that makes it highly distinguishable. 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 SLO policy definition.
Suggestions
Expand the capability list with more concrete actions, e.g., 'configure burn-rate alerts, create 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 seeking this skill. | 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
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 genuinely useful, executable PromQL and Prometheus/alerting configurations for SLO implementation, which is its primary strength. However, it suffers from significant redundancy (the same availability SLI query appears 4+ times), includes generic SRE knowledge Claude already possesses (best practices, review cadences, SLI/SLO/SLA definitions), and lacks a clear implementation workflow with validation steps. Trimming redundancy and adding a sequential implementation guide would substantially improve it.
Suggestions
Remove duplicate PromQL queries - the availability SLI ratio appears at least 4 times; define it once and reference it.
Cut the 'Best Practices' list, 'SLO Review Process' section, and 'SLI/SLO/SLA Hierarchy' explanation - these are generic SRE knowledge Claude already knows.
Add a clear sequential implementation workflow (e.g., 1. Define SLIs → 2. Deploy recording rules → 3. Verify metrics are populating → 4. Add alerting rules → 5. Build dashboard) with explicit validation at each step.
Move the detailed Prometheus recording rules and alerting rules into a separate reference file, keeping only a concise example in the main skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Significant verbosity throughout. The SLI/SLO/SLA hierarchy explanation, 'Choose Appropriate SLOs' considerations, and best practices list are all things Claude already knows. The same PromQL queries are repeated multiple times (availability SLI appears at least 4 times). The review process section and best practices are generic SRE knowledge that adds no actionable value. | 1 / 3 |
Actionability | The skill provides fully executable PromQL queries, complete Prometheus recording rules, and concrete alerting rule YAML configurations. The error budget calculations include specific numeric examples, and the SLO definitions are copy-paste ready. | 3 / 3 |
Workflow Clarity | While individual components (SLIs, SLOs, recording rules, alerts) are well-defined, there's no clear sequential workflow for implementing SLOs from scratch. The review process section lists items but lacks validation checkpoints. There's no guidance on verifying that recording rules are working correctly before building alerts on top of them. | 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 document is a monolithic wall of content (~200+ lines) with substantial inline detail that could be split out. The dashboard section and multi-window burn rate section largely duplicate the alerting rules section. | 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.
- Repository
- Dicklesworthstone/pi_agent_rust
- Commit
6e3d68c
- 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.