observability-control

Manage observability stack lifecycle (start, stop, backup, restore, upgrade). Use when controlling the LGTM stack for Claude Code monitoring.

Quality

78%

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/observability-control/SKILL.md

Quality

Content

65%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 skill body is action-dense and mostly efficient, but its destructive/batch workflows lack validation checkpoints and its script references point to non-existent files while the real scripts sit unused. Tightening workflow validation and reconciling script paths would lift the weakest dimensions.

Suggestions

Add validation/verification steps after destructive and batch operations: confirm `backup/dashboards.json` is non-empty JSON after backup, verify dashboards loaded (e.g. re-fetch by UID) after restore, and check `tempo` is healthy before/after the fix-permissions volume recreation.

Reconcile the Scripts section with the actual bundle: either rename the scripts to start-stack.sh/stop-stack.sh/health-check.sh/backup-dashboards.sh/restore-dashboards.sh or update the references to the existing start.sh/stop.sh/status.sh/backup.sh/restart.sh, and make the Operations sections invoke the scripts instead of inlining duplicated commands.

De-duplicate the Tempo permission-fix block (present in both Operations and Troubleshooting) and replace the `/path/docker-compose.yml` placeholder in `restart` with the concrete compose path used by the other operations.

Dimension	Reasoning	Score
Conciseness	The body is largely lean — tables plus executable commands with little prose padding and no over-explanation of concepts Claude already knows — but the Tempo permission-fix block is duplicated in both Operations and Troubleshooting and the all-services status check is repeated, so minor trimming is possible; fits anchor 4 rather than the fully-lean 5.	4 / 5
Actionability	Concrete, copy-paste-ready docker/curl/jq commands cover the common cases, but small gaps exist: `restart` uses a placeholder `/path/docker-compose.yml` instead of the full path used elsewhere, and `restore` reads `backup/dashboards.json` rather than the timestamped path the backup produces — mostly executable with minor gaps, anchor 4.	4 / 5
Workflow Clarity	Operations are listed with clear commands and a recognizable sequence, but destructive/batch operations lack validation checkpoints: backup never verifies the dashboard export succeeded, restore never confirms dashboards loaded, and fix-permissions runs `docker volume rm` with no validation — per the rubric cap, missing validation in destructive/batch workflows caps this at 3.	3 / 5
Progressive Disclosure	Section structure is present and the Scripts section signals references, but every referenced script path (start-stack.sh, stop-stack.sh, health-check.sh, backup-dashboards.sh, restore-dashboards.sh) does not exist — the actual bundle has start.sh/stop.sh/status.sh/backup.sh/restart.sh — so navigation is broken and the command content that belongs in those scripts is inlined, fitting anchor 3.	3 / 5
	Total	14 / 20 Passed

Description

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

The description is concise, specific, and answers both 'what' and 'when' with a concrete trigger clause. Its only gap is slightly limited trigger-term synonym coverage.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions verbatim — 'start, stop, backup, restore, upgrade' — giving comprehensive coverage of the lifecycle operations, matching the anchor 5 example that enumerates several specific actions.	5 / 5
Completeness	Explicitly states both what ('Manage observability stack lifecycle (start, stop, backup, restore, upgrade)') and when ('Use when controlling the LGTM stack for Claude Code monitoring'), matching the anchor 5 of clearly answering both with a concrete trigger phrase.	5 / 5
Trigger Term Quality	Includes relevant natural terms ('observability stack', 'LGTM stack', 'Claude Code monitoring') a user would say, but lacks synonyms/extensions like 'monitoring stack', 'telemetry stack', or the individual tool names (Grafana/Loki/Tempo), so a few natural terms are missing.	4 / 5
Distinctiveness Conflict Risk	Targets a clear niche — the LGTM stack for Claude Code monitoring — with distinct triggers unlikely to fire for unrelated skills, matching the anchor 5 of minimal conflict risk.	5 / 5
	Total	19 / 20 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
referenced_paths_exist	Referenced path issues: 5 missing	Warning

	Total	15 / 16 Passed

Repository: fernandezbaptiste/Skrillz
Path: skills/observability-control/SKILL.md
Commit: 93ed392

Reviewed: 1 day 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.