Logging observability
Curated, auditable, benchmark-ready Agent Skills library for Claude Code, Codex, OpenCode, Cursor, and more.
npx -y skills add shinzoxD/knackbox --skill logging-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
- 28 days oldThe repository was created 28 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 logging, metrics, and tracing that operators can use under pressure. Use whenever the user asks about structured logs, metrics, OpenTelemetry, dashboards, SLIs/SLOs, alerting, or how to instrument a service for production debugging.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.0 KB, as published. Nobody here has run it
Logging & Observability
If you cannot diagnose it at 3 a.m., you did not finish the feature. Prefer high-cardinality-careful metrics, structured logs, and traces that connect them.
Three pillars (practical)
| Signal | Use for |
|---|---|
| Metrics | SLIs, alerts, capacity |
| Logs | rich context on discrete events |
| Traces | latency across services |
Workflow
- Define user journeys and SLIs (availability, latency, error rate).
- Identify golden signals per service.
- Specify structured log fields (request_id, tenant, error codes) — never secrets.
- Trace critical paths; propagation headers.
- Alert on symptoms (SLO burn) more than raw CPU when possible.
- Dashboard sketch: RED/USE + business KPI.
Output format
## Observability plan: <service>
### SLIs / SLOs
…
### Metrics
…
### Logs (fields & levels)
…
### Traces
…
### Alerts
…
### Privacy / cardinality risks
…
Rules
- Never log passwords, tokens, raw PII, or full payment payloads.
- Bound cardinality (no unbounded user IDs as metric labels).
- Correlate with a request/trace ID across services.
- Prefer logging errors with stable
error_codeover unique essay messages only. - Alerts need runbook links and human-actionable thresholds.
- Sampling traces is fine; always sample errors.
Edge cases
- Batch jobs: progress metrics, last success timestamp.
- Mobile/clients: privacy and volume constraints.
- Multi-tenant: tenant in logs/metrics with care for isolation and cardinality.