logging

name	logging
description	Use when creating, updating, reviewing, or debugging logs, structured logging, error logs, audit logs, request tracing, correlation IDs, log levels, or sensitive data redaction.

Logging

Use this skill for useful, safe, and consistent logging.

Rules

• Follow the project’s existing logging pattern.
• Do not add a new logger, monitoring tool, tracing system, or log transport unless already used or explicitly requested.
• Prefer structured logs when the project supports them.
• Use the correct log level.
• Log enough context to debug the issue, but keep logs minimal.
• Do not log secrets, tokens, passwords, cookies, private keys, payment data, signed URLs, or sensitive payloads.
• Mask or omit personal data unless the project has a safe policy for it.
• Do not use raw console.log, print, or temporary debug logs in production paths unless this is already the project pattern.
• Avoid noisy logs in hot paths, loops, and high-frequency events.
• Preserve existing error, response, logging, and test conventions.
• Avoid unrelated refactors.

Inspect First

Before changing logging code, check existing patterns for:

• logger utility
• log format
• log levels
• request/correlation ID
• error logging
• audit logging
• redaction helpers
• test style

Implementation Checklist

• Reuse the existing logger.
• Identify the event, failure, or state change worth logging.
• Choose debug, info, warn, or error according to project usage.
• Add safe context such as request ID, user ID, route, resource ID, status, duration, job ID, or error code.
• Redact or omit sensitive fields.
• Do not log full request/response bodies by default.
• Log errors at the correct boundary; avoid duplicate error logs across layers.
• Add or update tests if logging is tested.

Security Rules

• Never expose stack traces or internal errors to clients.
• Never log credentials, tokens, cookies, secrets, card data, private keys, or raw uploaded files.
• Do not log private message content or sensitive documents.
• Do not log signed URLs if they grant access.
• Avoid logging raw provider payloads unless safely redacted.
• Treat logs as a possible security boundary.

Audit Logs

Use audit logs for sensitive actions when the project supports them:

• login/security events
• permission or role changes
• billing changes
• data export or deletion
• admin actions
• ownership, tenant, or organization changes

Keep audit logs minimal, durable, and safe.

Failure Handling

• Logging failure should not usually break the main business flow.
• If logging is required for audit/compliance, handle failure explicitly.
• Do not hide real application failures behind logging errors.
• Do not leave empty catch blocks.

Tests

Cover relevant paths:

• important event is logged
• error path logs safe context
• sensitive data is not logged
• request/correlation ID is included when available
• raw debug logs are not left behind
• audit log is created when required

Output