log-improve

Review and improve backend application logging by reducing noise and correcting log levels.

1|Updated May 4, 2026
One-click install
npx skills add https://github.com/wesbragagt/nixos-config --skill log-improve-wesbragagt
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: log-improve
Source: https://github.com/wesbragagt/nixos-config/tree/main/home/skills/log-improve
Command: npx skills add https://github.com/wesbragagt/nixos-config --skill log-improve-wesbragagt

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Backend codebases accumulate noisy, mis-leveled, and duplicated log statements that drown out the signals needed to debug production issues, while careless cleanup risks deleting logs that represent important business milestones. ## Core Features & Use Cases - Noise Reduction: Identifies and removes or downgrades logs that narrate function entry, per-row progress, polling loops, and routine successes. - Level Correction: Maps ERROR/WARN/INFO/DEBUG/TRACE semantics onto the project's actual logging library (slog, logrus, zap, winston, pino, and others) without imposing foreign conventions. - Structured Context: Improves event naming and adds correlation identifiers like requestId, traceId, jobId, and durationMs while removing sensitive data such as tokens and PII. - Business Milestone Gate: Pauses to ask for clarification before touching logs that may represent billing, payments, ingestion, or audit milestones. - Use Case: Point it at a service module drowning in per-item INFO logs and duplicate exception logging; it consolidates them into a few structured boundary events while preserving the job_failed error trail. ## Quick Start Ask the assistant to review and improve the logging in the current service module, reducing noise while preserving business milestone logs.

Frequently Asked Questions about log-improve

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I reduce noisy logs in a backend service?

Identify logs that narrate function entry, per-row progress, polling loops, and routine successes, then remove or downgrade them. Keep logs for request boundaries, workflow transitions, external dependency failures, and final errors, preferring fewer richer structured events.

What log level should I use for retries and recoverable failures?

Use WARN for unexpected but recoverable states such as retries, degraded behavior, and partial failures. Reserve ERROR for exhausted retries, failed jobs, outages, and data-loss risk, and never log expected behavior as an error.

Does this work with logging libraries like zap, logrus, or winston?

Yes, the review first identifies the project's logging library and level vocabulary, then maps the principles onto whatever levels and structured-field conventions the project already uses rather than imposing a foreign scheme.

How do I avoid logging sensitive data like tokens or passwords?

Never log passwords, tokens, API keys, authorization headers, payment data, or unnecessary PII. Replace them with safe identifiers, counts, and summaries such as requestId, jobId, rowCount, and statusCode.

When should a log not be removed during cleanup?

Preserve logs representing business or operational milestones such as billing, payments, orders, ingestion, migrations, and audit checkpoints. When genuinely unsure whether a log is noise or a milestone, stop and ask for clarification before changing it.