observabilitylisted

# Skill: /observability ## Purpose Wire up dashboards, alerts, and health checks so a module's runtime behavior is visible from outside the code — without touching the module's internal logic. ## When to Use - A module has shipped and needs monitoring before it goes to production - An incident revealed that no one knew the service was degraded until a user complained - A health check endpoint is missing or incomplete - Metrics exist in logs but aren't surfaced anywhere queryable - The user says "add observability to X", "set up monitoring", or "I want alerts when X fails" ## Steps 1. **Identify the target.** If invoked with no argument, ask: "Which module or service should I add observability to?" If a path is given, read the relevant files. 2. **Assess what already exists.** Check for: - Existing health check endpoints (`/health`, `/status`, `/ready`) - Log aggregation setup (structured JSON logs, log levels) - Metrics emission (Prometheus counters/gauges, StatsD, OpenTelemetry) - Existing dashboards or alert rules 3. **Apply the 6 observability techniques as appropriate.** Use the question→technique matrix: | Question | Technique | |----------|-----------| | "Is the module alive?" | Health check endpoint returning `{"status": "ok", "checks": {...}}` | | "What is it doing?" | Structured logging with `logging.getLogger(__name__)` at INFO level on entry/exit | | "How fast is it?" | Timing with `time.perf_counter()` logged at DEBUG; or `opentel