dt-obs-services

Service performance monitoring with RED metrics (Rate, Errors, Duration) and runtime-specific telemetry for Java, .NET, Node.js, Python, PHP, and Go. Use when analyzing service health, SLA compliance, or runtime issues. Trigger: "service response time", "error rate", "throughput", "SLA compliance", "service mesh overhead", "JVM GC", "Java heap", "Node.js event loop", ".NET CLR", "Python threads", "PHP OPcache", "Go goroutines", "service performance", "p95 latency", "request failures", "database response time by name". Do NOT use for explaining existing queries, product documentation questions, infrastructure metrics (use dt-obs-hosts), log analysis (use dt-obs-logs), or distributed tracing workflows (use dt-obs-tracing).

Quality

83%

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

Quality

Content

72%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 well-structured with executable DQL examples and excellent progressive disclosure into verified reference files. Its main weakness is workflow clarity, where sequenced workflows are abstract and lack validation checkpoints.

Suggestions

Make the Common Workflows concrete and self-checking: replace high-level steps with the actual DQL commands to run and add a validation/check step (e.g., verify failure_count > 0 before reporting errors) to lift workflow_clarity.

Tighten 'Act First, Refine Later' by trimming the rationale paragraph and keeping the defaults table plus one concrete example, reducing explanatory padding.

Add one copy-paste ready snippet per runtime in the runtime section or ensure each runtime reference is reachable with a one-line example, to push actionability from good to fully executable coverage.

Dimension	Reasoning	Score
Conciseness	Mostly lean with pointers to references and compact metric tables, but sections like 'Act First, Refine Later' include rationale ('Why this matters: ...') that lightly over-explains intent Claude could infer; not a 5 because a few passages could be trimmed.	4 / 5
Actionability	Multiple complete, executable DQL snippets (timeseries with percentile/sum, fetch spans with fieldsAdd/summarize) and named metrics, but several sections defer detail to references rather than giving copy-paste coverage of every common case, which keeps it just below 5.	4 / 5
Workflow Clarity	Common Workflows are sequenced ('1. Check response time ... 2. Check error rate ...') but steps are high-level and lack concrete commands or validation checkpoints; per the anchor this is steps-listed-but-checkpoints-missing, and not lower because sequences are coherent.	3 / 5
Progressive Disclosure	Clear overview in SKILL.md with well-signaled, one-level-deep references ('See [references/service-metrics.md]') all verified to exist, and detail appropriately split across runtime-specific files; matches the clear-overview-with-one-level-deep-references anchor.	5 / 5
	Total	16 / 20 Passed

Description

95%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 specific, trigger-rich, and explicitly bounds its scope against sibling observability skills. It uses third-person voice and avoids fluff, fully covering both the 'what' and 'when' with concrete trigger phrases.

Dimension	Reasoning	Score
Specificity	Lists several concrete actions ('Service performance monitoring with RED metrics (Rate, Errors, Duration) and runtime-specific telemetry for Java, .NET, Node.js, Python, PHP, and Go') but the action set is monitoring-centric rather than a broad catalog, leaving minor coverage gaps versus the score-5 anchor.	4 / 5
Completeness	Explicitly answers both what (RED metrics + runtime telemetry for six runtimes) and when ('Use when analyzing service health, SLA compliance, or runtime issues' plus a concrete Trigger list), matching the clear-what-and-when-with-concrete-trigger-phrases anchor.	5 / 5
Trigger Term Quality	Comprehensive natural-term coverage including synonyms and runtime-specific phrases users actually say ('service response time', 'error rate', 'p95 latency', 'JVM GC', 'Node.js event loop', 'Go goroutines'), matching the comprehensive-synonyms anchor; not reduced to 4 because no common variation is missing.	5 / 5
Distinctiveness Conflict Risk	A clear niche (Dynatrace service observability) with an explicit 'Do NOT use for ...' boundary redirecting infrastructure, logs, and tracing to sibling skills (dt-obs-hosts, dt-obs-logs, dt-obs-tracing), giving minimal conflict risk.	5 / 5
	Total	19 / 20 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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: Dynatrace/dynatrace-for-ai
Path: skills/dt-obs-services/SKILL.md
Commit: 3287f9d

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.