Observability
40 portable full-SDLC agent skills for Claude Code, Cursor, Codex, and GitHub Copilot — deep-work autonomy, contract-guard for external interfaces, TDD, code review, PR babysitting. Install: npx github:IcodeNet/agent-skills
npx -y skills add IcodeNet/agent-skills --skill observabilityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 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.
What its author says it does
Copied from the file, not written here
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).
SKILL.md
2.7 KB, 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
- 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.
- 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).
- 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:
errorpages someone,warnis actionable later,infonarrates state changes. - 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.
- 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.
- 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).
- 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
Gives 0 of the 12 instructions most monitoring observability skills give
Counted across 481 of the 483 authors here whose files we hold, read 2026-08-06
- link every alert to a runbookin 43 of 481, across 35 files
- use structured json loggingin 36 of 481, across 31 files
- alert on user-facing symptomsin 20 of 481, across 15 files
- emit structured JSON logs with stable event namesin 18 of 481, across 13 files
- propagate trace context across boundariesin 16 of 481
- use histograms for latency trackingin 14 of 481, across 9 files
- use OpenTelemetry for distributed tracingin 13 of 481, across 8 files
- include a correlation ID on every log linein 13 of 481, across 8 files
- Define service level objectivesin 10 of 481, across 7 files
- Call useAzureMonitor before importing other modulesin 9 of 481, across 2 files
- stop and ask for clarification if inputs are missingin 9 of 481, across 2 files
- define on-call questions before adding telemetryin 9 of 481, across 4 files
Said here and by no other author read
- define one to three user-observable SLIs
- instrument the RED set per service
- instrument the USE set per resource
- trigger a failure to verify the signals
- review label cardinality before shipping
- reuse the 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.