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 skills add orlando-japan/claude-code-setting --skill logging-strategygit clone --depth 1 https://github.com/orlando-japan/claude-code-settingWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/orlando-japan/claude-code-setting/logging-strategy)<a href="https://agentmods.dev/skills/orlando-japan/claude-code-setting/logging-strategy"><img src="https://agentmods.dev/badge/skills/orlando-japan/claude-code-setting/logging-strategy/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/orlando-japan/claude-code-setting/logging-strategy"><img src="https://agentmods.dev/badge/skills/orlando-japan/claude-code-setting/logging-strategy.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00029 | $0.00923 |
| Opus 5 | $0.00015 | $0.00462 |
| Sonnet 5 | $0.00006 | $0.00185 |
| Haiku 4.5 | $0.00003 | $0.00092 |
Grade A, and why
logging-strategy 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 8d 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 — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Logging strategy
Logs are for two audiences: debugging a specific problem (you, tomorrow) and triggering alerts (a machine). Everything else is noise and cost.
The levels
Pick your levels deliberately — most teams over-use INFO.
- DEBUG — for a developer actively debugging; off in production.
- INFO — one line per request / job / transaction at most. Something a human might want to find later.
- WARN — something unusual that didn't fail but might. "Degraded to fallback cache." Actionable.
- ERROR — the operation failed. Someone should know. Includes enough context to reproduce.
- FATAL / CRITICAL — the process is about to exit or the system is unsound. Pages someone.
Structured, always
Never log free-text when you could log structured fields. user_id=42 event=login status=ok latency_ms=87 is searchable and aggregatable. "User 42 logged in successfully in 87ms" is not.
Use the platform's structured logger: zap, pino, structlog, slog. Emit JSON.
Every log line should have
- Request ID (correlates across services)
- User ID (with privacy rules — see below)
- Event name (machine-readable)
- Timestamp (the framework adds this)
- Level
- Service / component
Beyond that, fields that matter for this specific event.
Never log
- Passwords, tokens, API keys, session cookies. Redact at the boundary, not "promise to remember."
- PII unless the event requires it. "User logged in" doesn't need their email.
- Full request bodies. Log the shape, not the payload.
- Full response bodies. Same.
- Stack traces to end users. They get a request ID; the log has the trace.
- Successful happy paths at INFO. "Cache hit" does not belong in a log.
What to log
At INFO (one per logical unit of work):
- Request received + request completed (with status and latency)
- Job started + job completed
- State transition of a domain object ("order → paid")
At WARN:
- Fallback taken ("primary cache unavailable, using local")
- Retry happened
- Slow query (above threshold)
- Deprecated code path hit
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.
- 8d ago First seen · 103 lines · 29 tokens per session scan A 2a13857d64e9
logging-strategy is a skill published in the GitHub repository orlando-japan/claude-code-setting (2 stars, last pushed 3mo ago), licensed MIT. It adds 29 tokens to every session and 923 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
analyze-logs
Analyze application logs from the .evlog/logs/ directory. Use when debugging errors, investigating slow requests, understanding request patterns, or answering questions about application behavior. Reads structured NDJSON wide events written by evlog's file system drain.
monitoring-observability
Monitoring and observability patterns for Prometheus metrics, Grafana dashboards, Langfuse v4 LLM tracing (astype, scorecurrentspan, shouldexportspan, LangfuseMedia), and drift detection. Use when adding logging, metrics, distributed tracing, LLM cost tracking, or quality drift monitoring.
datadog
Full-stack observability with Datadog APM, logs, metrics, synthetics, and RUM. Use when implementing monitoring, tracing, alerting, or cost optimization for production systems.
Logging and Observability Guard
Ensure code changes keep logs/metrics/traces useful for debugging failures and regressions.
superlog-debug
Pull production observability context from the Superlog MCP to ground debugging, incident response, and 'how is this behaving in prod right now?' questions. Triggers whenever the user is investigating a bug, regression, or incident; asking about real traffic, error rates, latency, or throughput; validating a deploy…
logging-observability-standards
When setting up telemetry, debugging distributed systems, or standardizing application output.