Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/kraitdev/skill.md/logging-observability-standardsnpx skills add KraitDev/skiLL.Md --skill logging-observability-standardsgit clone --depth 1 https://github.com/KraitDev/skiLL.MdWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00023 | $0.01789 |
| Opus 5 | $0.00012 | $0.00894 |
| Sonnet 5 | $0.00005 | $0.00358 |
| Haiku 4.5 | $0.00002 | $0.00179 |
Grade A, and why
logging-observability-standards scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 187 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Logging & Observability Standards
Purpose
Logs are the black box recorder of your system. When failures happen at 2 AM in production, logs are your only witness. This skill ensures application state and failures are highly searchable, machine-readable, and traceable across system boundaries WITHOUT leaking sensitive user data.
When to use
- Bootstrapping a new backend microservice or monolithic API
- Refactoring code filled with disorganized
console.logorprintstatements - Designing a system that spans multiple services/functions
- Setting up monitoring, alerting, and debugging infrastructure
When NOT to use
- Application performance monitoring (APM) - related but different concern
- Security incident response (use SIEM/security tools)
- User analytics (different use case, different tool)
Inputs required
- Backend service with multiple endpoints/functions
- Logging infrastructure (ELK, DataDog, Grafana Loki, CloudWatch, etc.)
- Understanding of structured logging concepts
Workflow
- Implement Structured Logging: Configure logger to output NDJSON (Newline Delimited JSON) instead of plain text
- Inject Context: Attach a
correlation_id(ortrace_id) at HTTP entry point and pass through all downstream calls - Standardize Levels: ERROR (system broken), WARN (unexpected but recovered), INFO (lifecycle), DEBUG (verbose tracing)
- Sanitize Data: Implement redaction middleware to mask credentials, tokens, and PII before logs hit the stream
- Add Request Context: Log request duration, status code, user context (anonymized), and performance metrics
- Trace Async Flows: Pass correlation ID through event handlers, message queues, and inter-service calls
- Monitor Log Health: Alert on high ERROR rates, unexpected patterns, or missing correlation IDs
Rules
- MUST output JSON in production environments (not plain text)
- MUST include Request ID/Correlation ID in all HTTP requests
- MUST NEVER log raw passwords, session tokens, or financial data
- MUST log full stack traces for ERROR level (for debugging)
- MUST log only message and context for WARN/INFO (not verbose)
- MUST redact/sanitize any PII before log emission
- MUST include timestamps in UTC
- MUST standardize key names across all logs
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 187 lines · 23 tokens per session scan A ccec2f073c82
logging-observability-standards is a skill published in the GitHub repository KraitDev/skiLL.Md (7 stars, last pushed 2mo ago), licensed MIT. It adds 23 tokens to every session and 1,789 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
health-check-endpoints
Implements liveness and readiness health check endpoints following Kubernetes probe conventions. Covers response schema, dependency checks, Kubernetes probe config, and circuit breaker integration. Invoked when the user asks to add health checks, implement a /health endpoint, or set up Kubernetes probes.
review-logging-patterns
Review code for logging patterns and suggest evlog adoption. Optionally use @evlog/cli (evlog init to wire evlog, evlog agents to write the conventions into AGENTS.md, evlog map to score entry-point coverage, --baseline to gate regressions in CI) on Nuxt, Nitro, Next.js, TanStack Start, and Hono. Guides setup on those…
build-audit-logs
Build or review audit trails in TypeScript/JavaScript apps using evlog (pipelines, typed actions, denials, retention, compliance-style reviews). For application code, not for extending the evlog package.
create-evlog-framework-integration
Create a new evlog framework integration to add automatic wide-event logging to an HTTP framework. Use when adding middleware/plugin support for a framework (e.g., Koa, H3 standalone, Deno Fresh, etc.) to the evlog package. Covers source code, build config, package exports, tests, example app, and all documentation.
create-evlog-adapter
Create a new built-in evlog adapter to send wide events to an external observability platform. Use when adding a new drain adapter (e.g., for Elasticsearch, Honeycomb, SigNoz, etc.) to the evlog package. Covers source code, build config, package exports, tests, e2e, and all documentation.
write-evlog-content
Write, review, and rewrite any evlog content: a docs page, the landing, a blog post, a package README, a skill, an AGENTS.md, a changeset. Load before drafting or editing prose in apps/docs/content, before writing a blog post, before touching a SKILL.md or an AGENTS.md, and whenever content is reviewed for voice…