Write a monitoring setup guide for a service — defining what to measure, how to alert on it, and how to build the observability stack covering the four golden signals, business metrics, log strategy, distributed tracing, alerting rules, dashboard layout, and observability debt. Use when asked to set up monitoring for a service, define alerting strategy, write an observability plan, create a dashboard specification, or document logging standards for a team. Produces a metric definitions table, alert rules specification, dashboard layout wireframe, log schema, tracing setup checklist, and monitoring gap analysis.
▸Service name and description — what the service does and its role in the system
▸Tech stack — language, framework, and infrastructure (e.g. Go/gRPC on Kubernetes, Python/FastAPI on ECS)
▸Current monitoring tooling — Datadog, Prometheus + Grafana, CloudWatch, New Relic, Honeycomb, or none yet
▸Key user journeys — the 2–4 most important things a user or consumer does with the service (these drive what to alert on)
▸Existing alerts — paste any existing alert configurations or describe what's currently monitored
✅ The bar it holds itself to
Every skill in this library self-verifies — these are this skill's own quality checks, straight from its definition.
✓Every alert has a named on-call action — no alert says "investigate" without specifying what to investigate first
✓Alert thresholds are calibrated against production baselines, not set to default values from a template
✓Structured logging is implemented — no unstructured text log lines in production
✓PII is explicitly excluded from logs — a named engineer has verified this
✓Distributed tracing is propagating trace IDs across all service boundaries (verify with a test request)
✓The primary dashboard answers "is the service healthy?" in under 10 seconds — no hunting for the right panel
✓Business metrics are tracked alongside infrastructure metrics — not just four golden signals
✓Observability debt items have owners and dates — not just "would be nice to have"
⚠️ What it refuses to do
Do not create alerts without a specific on-call action — an alert that just says "investigate" trains engineers to ignore it
Do not set alert thresholds from a template without calibrating against production baselines — uncalibrated thresholds cause either alert fatigue or missed incidents
Do not log PII, tokens, or secrets — a logging standard is incomplete without an explicit list of what must never be logged
Do not measure only the four golden signals without adding at least one business metric alert — infrastructure health can be green while the business-critical path is silently failing
Do not deploy distributed tracing without verifying that trace IDs propagate across all service boundaries — partial tracing is worse than no tracing because it produces misleading incomplete traces
Install
npx pm-claude-skills add --agent claude # or codex · cursor · gemini · hermes
# or one-line MCP (every skill, any client):
claude mcp add pm-skills -- npx -y pm-claude-skills-mcp