CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

82

Quality

77%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

SecuritybySnyk

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.md
SKILL.md
Quality
Evals
Security

Quality

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.

DimensionReasoningScore

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.

DimensionReasoningScore

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.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
Dicklesworthstone/pi_agent_rust
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.