agentsclimarketplace
Sign in

Observability

Skill IcodeNet/agent-skills/skills/observability

Design metrics, logs, traces, alerts, and SLOs alongside a feature or service. Use when adding observability, defining SLIs/SLOs, designing dashboards or alerts, or when a feature is about to ship with no way to tell if it works in production. Do not use for handling a live outage (use incident-response).From its SKILL.md

Install
npx -y skills add IcodeNet/agent-skills --skill observability

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.7 KB, 544 tokens by cl100k_base, as published. Nobody here has run it

Observability

If you can't tell within minutes that it broke in production, it isn't done. Design the signals with the feature, not after the incident.

Workflow

  1. Define "healthy" for this feature — 1–3 user-observable outcomes (request succeeds within X ms, job completes, message processed exactly once). These become your SLIs.
  2. Metrics — instrument the RED set per service/endpoint (Rate, Errors, Duration) and the USE set per resource (Utilization, Saturation, Errors) where relevant. Name metrics per the project's existing convention; add labels for the dimensions you'll actually filter by — not unbounded ones (no user-ids as labels).
  3. Logs — structured (key=value/JSON), one event per line, at boundaries and failures. Every error log answers: what operation, on what input (id, not payload), failed how, correlation id. No PII/secrets. Log levels mean something: error pages someone, warn is actionable later, info narrates state changes.
  4. Traces — propagate the correlation/trace id across service and queue boundaries the feature touches. Span the operations you'll want to see in a slow-request investigation.
  5. Alerts — alert on symptoms (SLO burn, error rate, latency) not causes (CPU). Every alert has: threshold with rationale, runbook link, and an owner. If it can't wake someone with a next action, it's a dashboard panel, not an alert.
  6. SLOs — for services with consumers: target (e.g. 99.9% success over 30d), measurement query, and the error budget policy (what stops when the budget burns).
  7. Verify the signals — trigger a failure in a test environment and confirm the metric moves, the log line appears, and the alert fires. Unverified observability is decoration.

Constraints

  • Reuse the project's existing observability stack and conventions; don't introduce a second metrics system for one feature.
  • Cardinality is a cost: review label sets before shipping.
  • Dashboards answer questions ("is checkout healthy?"), not display everything collected.

Verification

  • SLIs defined from user-observable outcomes
  • RED/USE instrumentation added where applicable
  • Structured logs at boundaries/failures, no PII
  • Correlation id propagates across the feature's boundaries
  • Alerts have thresholds, owners, runbook links
  • Signals verified by triggering a failure

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 1 of the 12 instructions most monitoring observability skills give in 544 tokens

Counted across 530 of the 532 authors here whose files we hold, read 2026-09-06

  • Use structured JSON loggingin 40 of 530, across 36 files
  • Link every alert to a runbookin 29 of 530, across 27 files
  • Attach correlation IDs to every log linein 19 of 530, across 16 files
  • Alert on symptoms rather than causeshere, and in 19 of 530, across 17 files
  • Use OpenTelemetry for distributed tracingin 15 of 530, across 14 files
  • Alert on symptoms users feelin 15 of 530, across 13 files
  • Implement health check endpointsin 14 of 530, across 10 files
  • Inspect existing dashboards firstin 12 of 530, across 4 files
  • Build the minimum useful boardin 12 of 530, across 4 files
  • Start from operator questionsin 12 of 530, across 4 files
  • Propagate trace context across boundariesin 11 of 530, across 10 files
  • Include trace id in all log entriesin 10 of 530, across 9 files

Said here and by no other author read

  • Define healthy for this feature
  • Instrument the RED and USE sets
  • Use structured logs at boundaries
  • Verify the signals in a test environment
  • Reuse the projects existing observability stack

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.