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".
57
50%
Does it follow best practices?
Impact
Pending
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 clearly defines its scope in the SRE/reliability engineering domain. It provides specific actions, explicit trigger guidance with natural user phrases, and uses domain-specific terminology that makes it highly distinguishable from other skills. The third-person voice is correctly used throughout.
| 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 including availability, latency, error rates) and 'when' (explicit 'Use when' clause plus specific trigger phrases). Fully meets the criteria for 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', 'reliability targets', 'service health', 'SLAs', 'availability', 'latency', 'error rates'. Good coverage of both acronyms and natural phrases. | 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', 'SLO', 'SLI' makes it highly distinctive 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 rather than instructive, explaining what SLAs/SLIs/SLOs are and what the skill 'will do' without providing any concrete, actionable guidance. It lacks executable code, YAML schemas, specific commands, or real examples. The content is highly repetitive, with the same concepts restated across Overview, How It Works, When to Use, Examples, and Instructions sections.
Suggestions
Replace the abstract descriptions with concrete YAML schema examples for SLI/SLO/SLA definitions (e.g., a complete sli-definitions.yaml template with actual fields and values)
Add executable code or commands for error budget calculation, such as a Python snippet or formula with concrete inputs and expected outputs
Consolidate the redundant sections (Overview, How It Works, When to Use) into a single brief overview, and use the saved space for actionable content like example configurations and validation steps
Provide actual bundle files (e.g., sli-definitions.yaml template, error budget calculator script) and reference them with clear navigation from the SKILL.md
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose with extensive explanation of concepts Claude already knows (what SLAs, SLIs, and SLOs are). Sections like 'Overview', 'How It Works', and 'When to Use This Skill' repeat the same information multiple times. The 'Best Practices' and 'Integration' sections are generic platitudes that add no actionable value. | 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 outputs. The 'Instructions' section is a vague numbered list with no specifics on how to actually perform any step. | 1 / 3 |
Workflow Clarity | The Instructions section lists steps but provides no concrete commands, no validation checkpoints, and no feedback loops. Steps like 'Configure automated SLI data collection' and 'Calculate error budgets based on SLOs' are entirely abstract with no indication of how to actually accomplish them. | 1 / 3 |
Progressive Disclosure | Monolithic wall of text with no bundle files to reference. References a path (${CLAUDE_SKILL_DIR}/slos/sli-definitions.yaml) that doesn't exist in the bundle. The 'Resources' section lists generic external references without links. Content is poorly organized with redundant sections that could be consolidated. | 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 | |
3a2d27d
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.