craft-observabilitylisted

The Craftsman standard for production observability — error tracking (Sentry), metrics & dashboards (Grafana), structured logging, tracing, SLOs, and alerting. Use this WHENEVER the work touches observability in any form: adding or reviewing Sentry, wiring Grafana/Prometheus/OpenTelemetry, setting up structured logs, defining alerts or SLOs, instrumenting a service, debugging "we have no visibility into X", or making a service observable/production-ready *on the monitoring side*. Trigger even when the user only says "add monitoring", "why can't we see errors", "set up dashboards", or "make this observable" without naming a specific tool. Deploy/runtime/CI production-readiness belongs to craft-infra; a *whole-project* readiness assessment across every surface is craft-audit, which routes here for the observability slice.
atifgul99/craftsman-marketplace · ★ 1 · Code & Development · score 65

Install: claude install-skill atifgul99/craftsman-marketplace

# Observability Craft This skill encodes one engineer's standard for making a service observable, applied the same way across every repo. The **method and opinions** live here; the **project specifics** (which logger, which DSN, which dashboard) live in the target repo's code and config — always discover them, never assume or hardcode. ## Operating principle — discover before you build Different repos already have different pieces. Before adding anything, spend two minutes mapping what exists so you extend rather than duplicate: - `package.json` / lockfile → is `@sentry/*`, `pino`/`winston`, `prom-client`, `@opentelemetry/*` already present? - `grep` for an existing logger, `Sentry.init`, `/health`, `/metrics`, or an env schema (`env.ts`, `config.ts`) — wire into these, don't fork them. - Deployment target (serverless vs long-lived) decides the metrics approach — see `references/serverless-vs-server.md` before reaching for `prom-client`. State what you found, then propose the smallest set of additions that closes the gaps. ## The four pillars (do them in this order) 1. **Errors** — Sentry first. It's the highest signal-per-minute. See `references/sentry.md`. 2. **Structured logs** — JSON logs with a request/trace id, never `console.log` in production code. See `references/logging.md`. 3. **Metrics & dashboards** — Grafana over a metrics source appropriate to the runtime. See `references/grafana.md`. 4. **SLOs & alerts** — alerts ride on user-facing symptoms