CtrlK
BlogDocsLog inGet started
Tessl Logo

observability-monitoring-slo-implement

You are an SLO (Service Level Objective) expert specializing in implementing reliability standards and error budget-based engineering practices. Design comprehensive SLO frameworks, establish meaningful SLIs, and create monitoring systems that balance reliability with feature velocity.

37

Quality

35%

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 ./plugins/AI-Agents-Safe-Coding-Skills/skills/observability-monitoring-slo-implement/SKILL.md

The canonical home for this skill is observability-monitoring-slo-implement in rmyndharis/antigravity-skills

SKILL.md
Quality
Evals
Security

Quality

Content

25%Scale 1-5

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

This skill is a hollow shell — it provides no concrete, actionable guidance for SLO implementation. The instructions are entirely meta-level ('apply best practices,' 'provide actionable steps') without any actual SLI definitions, metric examples, alerting configurations, or error budget calculations. The referenced playbook file doesn't exist in the bundle, leaving the skill with no substantive content at any level.

Suggestions

Add concrete, executable examples: SLI metric definitions (e.g., Prometheus queries for availability/latency), SLO target-setting templates, and error budget calculation formulas.

Replace the abstract instructions ('Clarify goals, apply best practices') with a specific multi-step workflow: e.g., 1. Identify critical user journeys → 2. Define SLIs with specific metric queries → 3. Set SLO targets based on historical data → 4. Configure error budget alerts → 5. Validate with burn-rate windows.

Either provide the referenced `resources/implementation-playbook.md` bundle file with detailed patterns, or inline the essential content directly in the SKILL.md.

Add a concrete example of an end-to-end SLO implementation for a common service type (e.g., an HTTP API with availability and latency SLOs), including specific metric queries and alert thresholds.

DimensionReasoningScore

Conciseness

The skill repeats the description in the body, includes a 'Context' section that restates what Claude already knows about SLOs, and has 'when to use/not use' sections that are somewhat generic. However, it's not excessively verbose — it's moderately padded rather than severely so.

3 / 5

Actionability

The instructions are entirely vague: 'Clarify goals,' 'Apply relevant best practices,' 'Provide actionable steps and verification' — these are meta-instructions with zero concrete guidance. No code, no specific commands, no examples of SLI definitions, no metric queries, no dashboard configurations. The skill delegates everything to a referenced file that doesn't exist in the bundle.

1 / 5

Workflow Clarity

There is a rough sequence implied (clarify goals → apply practices → validate → verify), but the steps are so abstract they provide no real workflow. No validation checkpoints, no feedback loops, no concrete sequencing of SLO implementation steps like defining SLIs, setting targets, configuring alerts, or reviewing error budgets.

2 / 5

Progressive Disclosure

The skill references `resources/implementation-playbook.md` for detailed patterns, which is a reasonable disclosure strategy, but no bundle files are provided — meaning the reference is broken. The main file itself contains almost no substantive content to serve as a useful overview, so the split is premature: there's nothing meaningful at the top level and nothing at the referenced level either.

2 / 5

Total

8

/

20

Passed

Description

45%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.

The description identifies a clear domain (SLO engineering) with some specific actions but remains at a relatively high level without concrete deliverables or outputs. It critically lacks a 'Use when...' clause, making it harder for Claude to know when to select this skill. The use of second-person voice ('You are') is also problematic—descriptions should use third person.

Suggestions

Add an explicit 'Use when...' clause with trigger phrases such as 'Use when the user asks about SLOs, SLIs, error budgets, reliability targets, uptime goals, or burn rate alerts'.

Rewrite in third person voice (e.g., 'Designs comprehensive SLO frameworks...') instead of second person ('You are an SLO expert').

Include more concrete actions and natural synonyms like 'define availability targets', 'calculate error budgets', 'set up burn rate alerting', 'establish latency and throughput SLIs'.

DimensionReasoningScore

Specificity

Names the domain (SLO/reliability engineering) and mentions a few actions like 'design SLO frameworks', 'establish SLIs', and 'create monitoring systems', but these are still fairly high-level and not deeply concrete (e.g., no mention of specific outputs, formats, or detailed sub-tasks).

3 / 5

Completeness

Provides a reasonable 'what' (design SLO frameworks, establish SLIs, create monitoring systems) but has no explicit 'when' clause or trigger guidance. The rubric states a missing 'Use when...' clause should cap completeness at 3, and the 'what' is only moderately clear, placing this at a 2.

2 / 5

Trigger Term Quality

Includes relevant domain terms like 'SLO', 'Service Level Objective', 'SLIs', 'error budget', 'reliability', and 'monitoring systems'. However, it misses common natural user phrases like 'uptime', 'availability', 'latency targets', '9s of reliability', 'alerting', or 'burn rate'.

3 / 5

Distinctiveness Conflict Risk

SLO/SLI/error budget engineering is a fairly specific niche that is unlikely to overlap heavily with most other skills. However, there could be minor overlap with general monitoring, observability, or DevOps/SRE skills due to the broad mention of 'monitoring systems' and 'reliability'.

4 / 5

Total

12

/

20

Passed

Validation

90%

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

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

10

/

11

Passed

Repository
administrakt0r/AI-Agents-Safe-Coding-Skills
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.