dt-obs-services

Service metrics, RED metrics (Rate, Errors, Duration), and runtime-specific telemetry for .NET, Java, Node.js, Python, PHP, and Go applications.

Quality

52%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/dt-obs-services/SKILL.md

Quality

Discovery

32%

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 identifies its domain (service metrics and runtime telemetry) and lists supported languages, but reads more like a topic label than an actionable skill description. It lacks concrete actions the skill performs and has no explicit trigger guidance ('Use when...'), making it difficult for Claude to confidently select this skill over others in a large skill set.

Suggestions

Add a 'Use when...' clause with explicit triggers, e.g., 'Use when the user asks about monitoring service health, setting up RED metrics, or instrumenting applications for observability.'

List specific concrete actions the skill performs, e.g., 'Configures RED metric dashboards, instruments application code for telemetry collection, sets up alerting on error rates and latency.'

Include additional natural trigger terms users might say, such as 'monitoring', 'observability', 'latency', 'error rate', 'APM', 'tracing', or 'Prometheus/Grafana'.

Dimension	Reasoning	Score
Specificity	The description names the domain (service metrics, RED metrics) and lists specific runtime technologies, but doesn't describe concrete actions like 'configure dashboards', 'set up alerts', or 'instrument code'. It tells what it covers but not what it does.	2 / 3
Completeness	The description only addresses 'what' at a topic level (service metrics and telemetry) but completely lacks a 'when should Claude use it' clause. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and since the 'what' is also weak (no concrete actions), this scores a 1.	1 / 3
Trigger Term Quality	Includes some useful keywords like 'RED metrics', 'Rate, Errors, Duration', 'telemetry', and specific language names (.NET, Java, etc.), but misses common user terms like 'monitoring', 'observability', 'latency', 'throughput', 'APM', 'tracing', or 'Prometheus'.	2 / 3
Distinctiveness Conflict Risk	The mention of RED metrics and specific runtime languages provides some distinctiveness, but 'service metrics' and 'telemetry' are broad enough to overlap with general observability, monitoring, or infrastructure skills.	2 / 3
	Total	7 / 12 Passed

Implementation

72%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a well-structured skill that effectively serves as an overview document with clear progressive disclosure to runtime-specific and detailed query references. The actionability is strong with executable DQL examples throughout. The main weaknesses are moderate verbosity in the agent instructions and use-case listings, and workflows that lack concrete validation or decision-point details.

Suggestions

Tighten the 'When to Use This Skill' and 'Response Construction Guidelines' sections—much of this is general agent behavior Claude already knows (e.g., 'don't overwhelm with all 6 runtimes').

Add concrete validation or decision points to workflows, e.g., 'If error_rate > 5%, escalate to span-based analysis for error details' rather than generic numbered steps.

Dimension	Reasoning	Score
Conciseness	The skill is reasonably efficient but includes some redundancy—the 'When to Use This Skill' section, the intent-mapping table, and the response construction guidelines add bulk that could be trimmed. The runtime-specific section is well-structured as pointers, but the repeated '→ For detailed queries' pattern and verbose use-case bullet lists add moderate bloat.	2 / 3
Actionability	The skill provides concrete, executable DQL queries for each capability area (RED metrics, SLA compliance, messaging, service mesh). The examples are copy-paste ready with real metric names, aggregation functions, and unit conversions. The agent instructions table and query construction patterns give specific, actionable guidance.	3 / 3
Workflow Clarity	Workflows are listed but lack explicit validation checkpoints or feedback loops. The 'Service Health Check' and 'Runtime Troubleshooting' workflows are high-level sequences without concrete validation steps (e.g., what to do if metrics look anomalous, how to verify query results). For a monitoring skill this is less critical than for destructive operations, but the workflows remain more like outlines than actionable procedures.	2 / 3
Progressive Disclosure	Excellent progressive disclosure structure: the SKILL.md serves as a clear overview with quick examples, and consistently points to one-level-deep reference files for each capability (service-metrics.md, java.md, nodejs.md, etc.). Navigation is well-signaled with inline links and a consolidated references section at the bottom.	3 / 3
	Total	10 / 12 Passed

Validation

100%

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 — 11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository: Dynatrace/dynatrace-for-ai
Commit: 4991356

Reviewed: 5 days 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.