observability-and-instrumentation

Instruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.

Quality

80%

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

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

A highly actionable, well-sequenced skill with strong code examples and explicit validation checkpoints. Its main weaknesses are conceptual re-explanation that bloats the body and a monolithic single-file structure whose one external reference points to a non-existent file.

Suggestions

Trim or move concept re-explanation (RED/USE mnemonic, 'metrics tell you that/traces where/logs why', the long entry-point justification) — Claude already knows these.

Either create references/observability-checklist.md so the trailing reference resolves, or inline the checklist and drop the dangling link.

Consider splitting the per-signal detail (logging, metrics, tracing, alerting) into one-level-deep reference files, leaving SKILL.md as an overview.

Dimension	Reasoning	Score
Conciseness	Mostly actionable and information-dense, but it re-explains concepts Claude already knows (the RED/USE rule of thumb, 'metrics tell you that, traces where, logs why') and the entry-point attribution argument (step 3) is a long prose justification that could be trimmed.	3 / 5
Actionability	Fully executable copy-paste TypeScript for structured logging, correlation-ID propagation, entry-point logging, a Prometheus histogram, and OpenTelemetry SDK setup, plus concrete tables and label/cardinality rules — covering the common cases.	5 / 5
Workflow Clarity	A clearly sequenced 7-step process ending in an explicit validation step ('7. Verify the telemetry itself') with feedback loops (force an error in staging → locate it by requestId), plus a closing verification checklist.	5 / 5
Progressive Disclosure	Sections are well-organized, but nearly all content is inlined in one ~215-line file, and the single external reference (../../references/observability-checklist.md) is not present in the bundle — references are neither real nor clearly signaled as one-level-deep.	3 / 5
	Total	16 / 20 Passed

Description

83%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 strong description: third-person voice, concrete signal types, and three explicit 'Use when' triggers that answer both what and when. Minor gaps are missing synonyms (monitoring/telemetry) and the disambiguation against sibling skills lives in the body rather than the description.

Suggestions

Add 'monitoring', 'telemetry', or 'observability' as trigger synonyms so the description surfaces for those wordings too.

Consider a brief 'Not for active debugging or performance tuning' clause in the description itself to reduce overlap with sibling skills.

Dimension	Reasoning	Score
Specificity	Names the domain ('production behavior is visible and diagnosable') and several concrete actions — 'logging, metrics, tracing, or alerting' — but the lead verb 'Instruments code' is generic and some adjacent actions (dashboards, sampling, runbooks) are absent.	4 / 5
Completeness	Explicitly states what it does ('Instruments code so production behavior is visible and diagnosable') and gives three concrete 'Use when...' trigger clauses, matching the score-5 anchor of answering both what and when with concrete triggers.	5 / 5
Trigger Term Quality	Uses natural phrases users say — 'logging', 'metrics', 'tracing', 'alerting', 'production issues are reported' — but omits common synonyms like 'monitoring', 'telemetry', or 'observability' itself.	4 / 5
Distinctiveness Conflict Risk	It has a clear production-instrumentation niche, but the 'production issues are reported' trigger lightly overlaps with debugging and the 'shipping any feature' trigger lightly overlaps with launch skills, which the body (not the description) disambiguates.	4 / 5
	Total	17 / 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: addyosmani/agent-skills
Path: skills/observability-and-instrumentation/SKILL.md
Commit: 48cb116

Reviewed: ~18 hours 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.