tracking-service-reliability
tessl i github:jeremylongshore/claude-code-plugins-plus-skills --skill tracking-service-reliabilityDefine 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".
Validation
81%| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
metadata_version | 'metadata' field is not a dictionary | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 13 / 16 Passed | |
Implementation
13%This skill content is largely descriptive rather than instructive, explaining concepts Claude already understands while failing to provide actionable guidance. It lacks executable code, concrete YAML schemas, actual metric queries, or specific configuration examples. The content reads more like documentation about what the skill does rather than instructions for how to actually implement SLI/SLO tracking.
Suggestions
Add a concrete YAML schema example for sli-definitions.yaml showing actual SLI/SLO definitions with specific values
Include executable code or commands for calculating error budgets and querying metrics (e.g., Prometheus queries, Datadog API calls)
Replace the abstract 'Examples' section with actual input/output examples showing real SLO definitions and calculations
Remove the 'Overview', 'How It Works', and 'When to Use' sections entirely - this information is redundant with the skill description and wastes tokens
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose with extensive explanation of concepts Claude already knows (what SLIs, SLOs, SLAs are). The 'Overview', 'How It Works', and 'When to Use' sections are redundant given the skill description. Multiple sections repeat the same information. | 1 / 3 |
Actionability | No executable code, commands, or concrete examples. The 'Examples' section describes what the skill 'will do' abstractly rather than showing actual implementation. No YAML schemas, no metric queries, no actual configuration examples. | 1 / 3 |
Workflow Clarity | The 'Instructions' section provides a numbered sequence of steps, but lacks validation checkpoints, specific commands, or feedback loops. No concrete guidance on how to verify SLI definitions are correct or how to validate metric collection is working. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files despite mentioning '{baseDir}/slos/sli-definitions.yaml'. The 'Resources' section lists external references but provides no links or file paths. Content that could be split (templates, examples) is either missing or inline. | 1 / 3 |
Total | 5 / 12 Passed |
Activation
100%This is an excellent skill description that follows best practices. It uses third person voice, provides specific concrete actions, includes a clear 'Use when' clause, and offers explicit trigger phrases. The domain-specific terminology (SLAs, SLIs, SLOs, error budgets) makes it highly distinctive and easy for Claude to select appropriately.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'Define and track SLAs, SLIs, and SLOs' with specific domains '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, and SLOs for service reliability') AND when ('Use when establishing reliability targets or monitoring service health') with explicit trigger phrases provided. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'define SLOs', 'track SLI metrics', 'calculate error budget', 'reliability targets', 'service health'. Includes both acronyms (SLA, SLI, SLO) and descriptive phrases users would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive niche focused on SRE/reliability engineering concepts. The specific terminology (SLA, SLI, SLO, error budget) creates clear boundaries that are unlikely to conflict with general monitoring or metrics skills. | 3 / 3 |
Total | 12 / 12 Passed |
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.