Production Observability
Make production behavior visible and diagnosable with structured logs, metrics, traces, and actionable alerts.
It explicitly requires structured logs, correlation IDs, allowlisted fields, and forbids logging secrets, tokens, passwords, and full PII, reducing leakage risk. It does not define telemetry-provider permissions, retention and access controls, cost limits, user confirmation, rollback, or full data-flow disclosure, and the skill itself lacks source attribution, so points are deducted.
The workflow is internally coherent from defining questions through signal selection, verification, and checklists, with reasonably concrete abnormal-path checks. However, environment requirements, versions, configuration, and diagnosable failure feedback are underspecified; examples focus mainly on Node/TypeScript, and no skill-specific reproduction was supplied. Static-review limits therefore apply and points are deducted.
The description and usage section cover logging, metrics, tracing, alerting, and production incidents, while excluding live debugging, performance optimization, and launch checklists. Trigger boundaries remain broad, non-Node/TypeScript environments and Chinese-team usage are not addressed, and some guidance assumes unconfigured OpenTelemetry or Prometheus components, so points are deducted.
The document has clear progressive structure with overview, triggers, process, rationalization table, red flags, and verification checklist, plus useful examples and limitations. The README supplies MIT licensing, maintainers, and installation entry points, but the selected skill lacks independent versioning, changelog, maintenance ownership, and update-path details; the referenced checklist was not included in the supplied skill evidence, so points are deducted.
The skill can directly guide an agent to define observability questions, select signals, implement structured logging, RED/USE metrics, tracing, and symptom-based alerts, giving it practical core value. It lacks complete stack-specific deliverable templates, configuration coverage, and verified outputs, so implementation still requires platform-specific work and review; static calibration caps the score at 7 and points are deducted.
The skill specifies runtime checks such as inducing failures, inspecting metrics, following traces, and test-firing alerts. The repository also shows a general CI workflow, but the supplied fixture does not cover this skill's key paths and no skill-specific results, third-party evidence, or independent reproduction record is provided, so only limited static evidence is credited.
- The mandatory request-ID pattern may conflict with existing trust boundaries, spoofable headers, and cross-service security policies; define trusted boundaries, generation rules, and conflict handling.
- Redaction, retention, access control, telemetry cost, sampling, and degraded-mode behavior are not covered in enough operational detail and should be added before production adoption.
- Versions, installation, configuration, and compatibility for OpenTelemetry, prom-client, alert backends, and tracing UIs are unspecified; confirm that the referenced observability-checklist.md is reachable.
What does this skill do, and when should you use it?
This skill provides a workflow for adding observability while building production features. It starts with the questions an on-call engineer must answer, then maps each question to structured logs, metrics, or distributed traces. It covers correlation IDs, RED and USE metrics, OpenTelemetry, symptom-based alerting, and verification of telemetry itself. It is a strong fit for teams shipping production services, but it does not replace vendor-specific monitoring setup.
It guides an agent to define 2–4 operational questions, design structured JSON events with correlation IDs, add RED/USE metrics and latency histograms, configure OpenTelemetry tracing, and create actionable symptom-based alerts. It also enforces bounded metric cardinality, excludes secrets and unredacted PII from logs, and verifies telemetry by inducing failures, sending test traffic, following requests, and test-firing alerts.
- A service engineer is adding an endpoint, background job, or external integration that will run in production.
- An on-call engineer needs better evidence after an incident was difficult to diagnose.
- A platform team is reviewing RED/USE metrics and alerting for services, queues, pools, or hosts.
- A reviewer is assessing a change that introduces I/O, retries, queues, or cross-service calls.
What are this skill's strengths and limitations?
- Covers the workflow from defining operational questions through verifying emitted telemetry.
- Clearly distinguishes the roles of logs, metrics, and traces.
- Gives concrete rules for structured events, correlation IDs, cardinality, sampling, and actionable alerts.
- Includes a practical verification checklist and anti-rationalization guidance.
- Does not provide complete configuration for a specific monitoring backend, alerting platform, or deployment environment.
- Examples focus on the TypeScript, Node.js, OpenTelemetry, and Prometheus ecosystem, so other stacks require adaptation.
- Alert thresholds, SLOs, and runbook contents must be decided for the actual system.
How do you install this skill?
Install the individual skill with the repository's skills CLI:
npx skills add addyosmani/agent-skills --skill observability-and-instrumentation
The README also documents integrations for several clients; consult the repository documentation for client-specific installation.
How do you use this skill?
Trigger it when adding telemetry to a production feature, for example: "Instrument this production endpoint with structured logs, RED metrics, OpenTelemetry tracing, and symptom-based alerts, then verify the telemetry." The supplied material does not define one universal invocation command for every client.
How does this skill compare with similar options?
The README names Superpowers and Matt Pocock's skills as related collections and points to a comparison document, but the supplied material does not provide a skill-specific side-by-side comparison.