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.

Quality

73%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/slo-implementation/SKILL.md

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 rich with executable PromQL/YAML and covers the SLO domain thoroughly, but it is padded with boilerplate and repeated formulas, lacks a sequenced implementation workflow with validation, and keeps everything monolithic in one file. Addressing redundancy and adding an explicit step-by-step workflow would most improve it.

Suggestions

Remove the generic "Instructions", "Do not use this skill when", and "Purpose" boilerplate, and de-duplicate the availability SLI formula that recurs across the SLI, SLO-example, recording-rule, and burn-rate sections.

Add an explicit sequenced implementation workflow (e.g. 1. Define SLIs → 2. Set SLO targets → 3. Add recording rules → 4. Configure multi-window alerts → 5. Verify alerts fire) with a validation/verification checkpoint.

Define the missing burn_rate_1h, burn_rate_6h, and burn_rate_30m recording rules that the alerting rules reference, or note explicitly that they follow the burn_rate_5m pattern.

Dimension	Reasoning	Score
Conciseness	The body is mostly useful executable code, but the generic "Instructions", "Do not use this skill when", and "Purpose" sections are boilerplate, and the same availability SLI formula is repeated in four places, so it could be noticeably tightened.	3 / 5
Actionability	Concrete, copy-paste-ready Prometheus recording rules, alerting rules, error-budget policy, and SLO YAML cover common cases, but alerts reference burn_rate_1h/6h/30m recording rules that are not actually defined in the provided rules.	4 / 5
Workflow Clarity	Content is organized topically rather than as a sequenced implementation workflow, and the "Instructions" section gives only a vague three-step sequence with no explicit validation checkpoints.	3 / 5
Progressive Disclosure	The ~250-line file is well-sectioned with headers but has no references; sizable blocks (recording rules, alerting rules, review process) are inlined that would be better split into one-level-deep reference files.	3 / 5
	Total	13 / 20 Passed

Description

88%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, third-person description that concretely states capabilities and provides explicit "Use when" triggers covering the SLO/SRE niche. Minor broadness in the SRE trigger and a few missing synonyms keep trigger quality and distinctiveness at 4 rather than 5.

Dimension	Reasoning	Score
Specificity	"Define and implement Service Level Indicators (SLIs) and Service Level Objectives (SLOs) with error budgets and alerting" lists four concrete actions (define SLIs, implement SLOs, error budgets, alerting) with comprehensive coverage of the SLO domain.	5 / 5
Completeness	The description explicitly answers both what ("Define and implement SLIs/SLOs with error budgets and alerting") and when ("Use when establishing reliability targets, implementing SRE practices, or measuring service performance") with concrete trigger phrases.	5 / 5
Trigger Term Quality	"establishing reliability targets, implementing SRE practices, or measuring service performance" provides good natural trigger phrases, though a few common variations/synonyms (e.g. "error budgets", "on-call") are not surfaced as triggers.	4 / 5
Distinctiveness Conflict Risk	The SLI/SLO/error-budget niche is clearly distinct, but the broad trigger "implementing SRE practices" creates minor overlap risk with general monitoring or SRE skills, keeping it just below a 5.	4 / 5
	Total	18 / 20 Passed

Validation

100%

Warnings & errors only

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: rmyndharis/antigravity-skills
Path: skills/slo-implementation/SKILL.md
Commit: 3eff4af

Reviewed: 5 days ago

Table of Contents

Discovery Implementation Validation

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.