observabilitylisted

# Purpose Instrument the project's services with structured logging and distributed tracing. Provide patterns for correlating logs, traces, and metrics when diagnosing issues. This skill focuses on code-level instrumentation -- what to log, how to propagate trace context, and how to correlate signals. **Placeholders used below:** `<mainApp>` = `project.json → mainApp` (the primary application), `<device>` = `project.json → device` (the edge/device service, if the project has one). Repos and their layout come from `project.json → repos`. # When to use - Adding structured logging to a new or existing service (`<mainApp>`, `<device>`). - Instrumenting code with OpenTelemetry distributed tracing. - Correlating logs with traces to diagnose latency or error issues. - Setting up log format standards for a new service. - Reviewing logging practices for PII/secret leakage. **Disambiguation -- observability vs monitoring:** If the task says "add logging," "add tracing," or "correlate logs with traces," use this skill. If it says "add metrics," "add Prometheus counters," or "create a Grafana dashboard," use `monitoring`. If investigation starts from log search or trace lookup, start here; if it starts from a Prometheus alert, start with `monitoring`. # When NOT to use - **Prometheus metrics, Grafana dashboards, or alert rules** -- use `monitoring`. - **Helm liveness/readiness probes** -- part of the project's deployment workflow (infra-pack skills when enabled). - **CI pipeline o