Define and track SLAs, SLIs, and SLOs for service reliability including availability, latency, and error rates. Use when establishing reliability targets or monitoring service health. Trigger with phrases like "define SLOs", "track SLI metrics", or "calculate error budget".
46
50%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/performance/sla-sli-tracker/skills/tracking-service-reliability/SKILL.mdQuality
Discovery
100%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 well-crafted skill description that hits all the key criteria. It provides specific actions, includes natural trigger terms users would say, explicitly addresses both what and when, and occupies a distinct niche in the SRE/reliability engineering space. The description uses proper third-person voice and is concise without being vague.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'Define and track SLAs, SLIs, and SLOs' with specific domains including 'availability, latency, and error rates'. Also mentions 'establishing reliability targets' and 'monitoring service health'. | 3 / 3 |
Completeness | Clearly answers both 'what' (define and track SLAs/SLIs/SLOs for service reliability) and 'when' (explicit 'Use when' clause plus specific trigger phrases). The description has a well-structured format with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would actually say: 'define SLOs', 'track SLI metrics', 'calculate error budget', 'SLAs', 'SLIs', 'SLOs', 'reliability targets', 'service health', 'availability', 'latency', 'error rates'. Good coverage of the domain vocabulary. | 3 / 3 |
Distinctiveness Conflict Risk | Occupies a clear niche around SRE/reliability engineering concepts (SLAs, SLIs, SLOs, error budgets). The specific terminology like 'error budget', 'SLOs', and 'SLI metrics' makes it highly distinct and unlikely to conflict with general monitoring or metrics skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
0%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is almost entirely descriptive and meta-level, explaining what it does rather than providing actionable instructions Claude can follow. It lacks any concrete code, YAML schemas, formulas (e.g., error budget calculation), or executable examples. The content is highly redundant, with multiple sections restating the same abstract concepts.
Suggestions
Replace the abstract descriptions with concrete YAML schema examples for SLI/SLO/SLA definitions, including a complete sample sli-definitions.yaml file
Add executable error budget calculation formulas and code (e.g., `error_budget = 1 - SLO_target`, burn rate calculations with actual math)
Remove redundant sections (Overview, How It Works, When to Use) and consolidate into a lean quick-start with a concrete worked example showing input request → output artifact
Provide actual monitoring tool integration examples (e.g., Prometheus queries, Datadog monitors) rather than abstract references to 'monitoring tools'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose with extensive explanation of concepts Claude already knows (what SLAs, SLIs, and SLOs are). The 'Overview', 'How It Works', and 'When to Use This Skill' sections are redundant with each other and with the description. Multiple sections restate the same information in slightly different ways. | 1 / 3 |
Actionability | No concrete code, commands, YAML schemas, or executable examples anywhere. The 'Examples' section describes what the skill 'will do' in abstract terms rather than showing actual output formats, configuration files, or calculations. The 'Instructions' are a vague numbered list with no specifics on how to actually perform any step. | 1 / 3 |
Workflow Clarity | The instructions list steps but provide no concrete details on how to execute them, no validation checkpoints, and no feedback loops. Steps like 'Configure automated SLI data collection' and 'Calculate error budgets based on SLOs' are stated without any specifics on tools, formulas, or verification methods. | 1 / 3 |
Progressive Disclosure | References a file path (${CLAUDE_SKILL_DIR}/slos/sli-definitions.yaml) but no bundle files exist. The content is a monolithic wall of text with no meaningful structure separating quick-start from advanced content. External references to 'Google SRE book' and generic guides are not actionable links. | 1 / 3 |
Total | 4 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
6e9558f
Table of Contents
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.