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.

61

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./tests/ext_conformance/artifacts/agents-wshobson/observability-monitoring/skills/slo-implementation/SKILL.md

The canonical home for this skill is slo-implementation in wshobson/agents

SKILL.md
Quality
Evals
Security

Quality

Content

57%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is technically substantive with concrete Prometheus configurations, but it is undermined by heavy repetition of the same SLI queries, alert expressions that depend on undefined recording rules, and a progressive-disclosure structure that cites reference files which do not exist in the bundle. It reads more as a reference manual inlined into SKILL.md than a workflow-oriented guide.

Suggestions

Define the missing burn_rate_1h, burn_rate_6h, and burn_rate_30m recording rules in the recording-rules section (or reuse the 5m rule consistently) so the multi-window burn-rate alerts are actually executable.

Create the referenced files (references/slo-definitions.md, references/error-budget.md, assets/slo-template.md) or remove the references, and move the full alerting rules and dashboard queries into those files to slim the body.

Deduplicate the PromQL SLI expressions (stated four times across the SLI, SLO example, and recording-rule sections) by defining them once and referencing the recording-rule names elsewhere, and add an explicit step-by-step implementation sequence with validation checkpoints (e.g., verify rules load, test alert firing).

DimensionReasoningScore

Conciseness

The same PromQL SLI expressions (availability and latency ratios) are repeated nearly verbatim four times across the SLI definitions, example SLO YAML, and recording rules sections, and the SLA/SLO/SLI hierarchy restates standard SRE knowledge. Mostly efficient structure, but the duplication and redundant explanation mean it could be tightened considerably, fitting anchor 3 rather than anchor 4's 'minor instances'.

3 / 5

Actionability

The recording rules, alert rules, and SLO/error-budget YAML are largely executable and copy-paste ready, matching anchor 4. It falls short of anchor 5 because the alert rules query burn_rate_1h, burn_rate_6h, and burn_rate_30m recording rules that are never defined (only burn_rate_5m is), and the Grafana dashboard is an ASCII sketch rather than a real dashboard spec.

4 / 5

Workflow Clarity

The body is organized by topic (define SLIs, set targets, calculate error budgets, implement, alert, review) which implies a sequence, but there is no explicit step-by-step implementation workflow with validation checkpoints (e.g., verifying recording rules loaded or testing alerts with sint-recorded data). This matches anchor 3: sequence present but checkpoints missing or implicit.

3 / 5

Progressive Disclosure

References are clearly signaled inline and consolidated in a 'Reference Files' section, but the bundle contains no references/ or assets/ directories, so all three referenced files (slo-definitions.md, error-budget.md, slo-template.md) are missing. Additionally, ~330 lines of full alerting rules and dashboard detail are inlined in SKILL.md where they belong in the reference files, matching anchor 3's 'content that should be separate is inline' rather than anchor 4's 'most content appropriately placed'.

3 / 5

Total

13

/

20

Passed

Description

87%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: third-person voice, concrete capabilities, and an explicit multi-phrase 'Use when' clause covering the SRE/reliability space. Minor room to broaden trigger synonyms (uptime, SLA, service levels) for even better recall.

DimensionReasoningScore

Specificity

"Define and implement Service Level Indicators (SLIs) and Service Level Objectives (SLOs) with error budgets and alerting" names the domain and several concrete capabilities (define, implement, error budgets, alerting). It stops just short of anchor 5 because adjacent concrete actions like burn-rate alerting, dashboards, or SLO review are absent.

4 / 5

Completeness

It explicitly answers 'what' ("Define and implement SLIs and SLOs with error budgets and alerting") and 'when' ("Use when establishing reliability targets, implementing SRE practices, or measuring service performance") with concrete trigger phrases, matching the anchor 5 example structure. Anchor 4 would require the 'when' clause to be less explicit, which it is not.

5 / 5

Trigger Term Quality

Natural trigger phrases include "establishing reliability targets", "implementing SRE practices", and "measuring service performance", plus the keywords SLIs, SLOs, error budgets, and alerting. A few common user variations (uptime, service levels, SLA) are missing, matching anchor 4 rather than the comprehensive synonym coverage of anchor 5.

4 / 5

Distinctiveness Conflict Risk

The SLO/error-budget/SRE niche is well-defined with distinct triggers, making confusion with generic monitoring or incident-response skills unlikely. It sits clearly at anchor 5; anchor 4 would imply meaningful overlap with a closely related skill, which the specialized terminology here avoids.

5 / 5

Total

18

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

referenced_paths_exist

Referenced path issues: 5 missing

Warning

Total

15

/

16

Passed

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.