CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

observability-engineer

Build production-ready monitoring, logging, and tracing systems. Implements comprehensive observability strategies, SLI/SLO management, and incident response workflows.

42

Quality

53%

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/antigravity-bundle-observability-monitoring/skills/observability-engineer/SKILL.md

The canonical home for this skill is observability-engineer in rmyndharis/antigravity-skills

SKILL.md
Quality
Evals
Security

Quality

Content

27%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 body is a persona résumé: a trigger section followed by exhaustive tool enumerations that add nothing Claude does not already know, with zero executable guidance. It reads as padding rather than instruction, and everything is inlined in one file with no progressive disclosure.

Suggestions

Replace the Capabilities/Knowledge Base enumerations with actionable content: example PromQL recording rules, an SLO/error-budget burn-rate formula, an OpenTelemetry collector config snippet, and a PagerDuty/Slack alert routing example.

Cut the ~180 lines of tool lists down to a few lines of domain-specific knowledge Claude genuinely lacks (e.g., team-specific SLO conventions, naming standards, runbook templates), which would take conciseness to the top anchors.

Move detailed capability catalogs into a references/ file (e.g. references/stacks.md) linked one level deep from SKILL.md, keeping the body as a lean overview with the Use/Do-not-use trigger sections.

DimensionReasoningScore

Conciseness

Roughly 180 of the 228 lines are 'Capabilities', 'Knowledge Base', and 'Behavioral Traits' enumerations of tools and concepts (Prometheus, Jaeger, ELK, PagerDuty, chaos engineering, SOC2) that Claude already knows, matching 'noticeably verbose; several unnecessary... padded sections'. Not 1 because the 'Use this skill when' / 'Do not use' sections are genuinely useful and there is no explanatory filler prose.

2 / 5

Actionability

The body provides no code, commands, PromQL examples, dashboard JSON, OpenTelemetry configs, or concrete procedures — instructions like 'Identify critical services, user journeys, and reliability targets' and 'Define signals, instrumentation, and data retention' only describe rather than instruct. This matches the 'entirely vague or abstract; only describes rather than instructs' anchor.

1 / 5

Workflow Clarity

The 'Instructions' section lists a coherent four-step sequence ending with 'Validate signal quality and reduce alert noise', and 'Response Approach' adds an eight-step sequence, so a sequence is present. However, checkpoints are implicit and steps are generic with no error-recovery guidance, matching 'steps listed but validation gaps; checkpoints missing or implicit' rather than 4.

3 / 5

Progressive Disclosure

The document has well-organized section headers and no nested-reference problem, but 150+ lines of capability catalogs that belong in separate reference files are fully inlined, and no bundle files or references exist at all. This matches 'some structure... content that should be separate is inline'; not 2 because structure is present and clear, not minimal.

3 / 5

Total

9

/

20

Passed

Description

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

A reasonably specific, third-person description that clearly states what the skill does, but it omits any 'use when' trigger guidance, which caps completeness and leaves common synonyms (alerting, metrics, dashboards, telemetry) uncovered. Adding an explicit trigger clause with those terms would move it close to the top anchors.

Suggestions

Append an explicit trigger clause to the description, e.g. 'Use when designing monitoring/logging/tracing systems, defining SLIs/SLOs and alerting strategies, or investigating production reliability or performance regressions.'

Include natural synonyms users actually say — alerting, metrics, dashboards, telemetry, APM, on-call — to improve trigger term coverage.

Mention concrete artifact outcomes (Prometheus/Grafana configs, OpenTelemetry instrumentation, runbooks) to sharpen the 'what' beyond generic verbs like 'build' and 'implements'.

DimensionReasoningScore

Specificity

The description lists several concrete actions ('Build production-ready monitoring, logging, and tracing systems', 'SLI/SLO management, and incident response workflows'), matching the 'several specific actions; minor gaps' anchor. It falls short of 5 because verbs remain generic and parts of the domain (alerting, dashboards, metrics, telemetry) are absent.

4 / 5

Completeness

The 'what' is clear (build monitoring/logging/tracing systems, observability strategies, SLI/SLO management, incident response), but there is no 'Use when...' clause or equivalent trigger guidance in the description, which caps completeness at 3 per the judging guidelines. The trigger guidance exists only in the body, not the description field.

3 / 5

Trigger Term Quality

Terms like 'monitoring', 'logging', 'tracing', 'SLI/SLO', and 'incident response' are natural user phrases, but common variations and synonyms such as 'alerting', 'metrics', 'dashboards', 'telemetry', and 'APM' are missing. This fits the 'some relevant keywords but missing common variations' anchor better than 4.

3 / 5

Distinctiveness Conflict Risk

The observability/SRE niche is well-defined ('production-ready monitoring, logging, and tracing systems', 'SLI/SLO management') with mostly distinct triggers, carrying only minor overlap risk with closely related skills such as general SRE or security-monitoring skills. Not 5 because terms like 'monitoring' and 'incident response' are broad enough to collide with adjacent skills.

4 / 5

Total

14

/

20

Passed

Validation

93%

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

CriteriaDescriptionResult

frontmatter_unknown_keys

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

Warning

Total

15

/

16

Passed

Repository

administrakt0r/AI-Agents-Safe-Coding-Skills

Path

plugins/antigravity-bundle-observability-monitoring/skills/observability-engineer/SKILL.md

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.