agentsclimarketplace

Logging

Skill andr-ca/agentharness/.claude/skills/logging

Portable engineering policies for coding agents — git, testing, logging, and language conventions written once and referenced everywhere

Install
npx -y skills add andr-ca/agentharness --skill logging

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 25 days oldThe repository was created 25 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.
  • 1 stars1 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

Use when adding logging to an application, reviewing log output, choosing log levels, structuring logs for observability, or configuring logging backends — covers structured logging, YAML config patterns, what NOT to log, and local vs. production output.

SKILL.md

3.5 KB, as published. Nobody here has run it

Logging

This skill is self-contained for day-to-day use. Deeper reference (needs the full harness checkout): patterns/logging/LOGGING_STANDARDS.md (full mandate and config schema), patterns/logging/logging.yaml.example (tested YAML template), patterns/logging/config_loader.py (Python reference implementation with 99% test coverage).

When this applies

Full structured logging with YAML config, multiple backends, and rotation is required at Production tier. Prototypes: print()/console.log() is fine. Internal tools: structured logging recommended, single-backend acceptable. Check the project's rigor tier first.

Log levels — pick the right one

LevelUse for
TRACEHigh-frequency per-call details; disabled in production by default
DEBUGDeveloper diagnostic info; disabled in production by default
INFONormal operational events (startup, request completed)
WARNINGSomething unexpected but recoverable; worth investigating
ERRORA real failure that the system couldn't recover from
CRITICALThe process must stop or data is corrupted

Rule of thumb: if you'd page someone at 3am, it's ERROR or CRITICAL.

Structured logging: message + fields, never string interpolation

# WRONG: unstructured — can't query or filter by user_id or duration
logger.info(f"Request completed for user {user_id} in {duration}ms")

# RIGHT: message is a static label; context is in structured fields
logger.info("request.completed", user_id=user_id, duration_ms=duration)
// Node/pino/winston equivalent
logger.info({ userId, durationMs }, 'request.completed');

What NOT to log

Never log: passwords, tokens, API keys, full credit card numbers, SSNs, session IDs, or any data under a PII/GDPR policy. Redact or omit before logging. If logging usefulness and secrecy conflict, redact. Do not log the secret "for completeness."

# WRONG: logs the raw token
logger.info("auth.token_issued", token=issued_token)

# RIGHT: log only what's safe to expose
logger.info("auth.token_issued", user_id=user_id, expires_at=exp)

Configuration: YAML template, not hand-rolled

Copy patterns/logging/logging.yaml.example as your starting point:

cp patterns/logging/logging.yaml.example config/logging.yaml

The template supports ${VAR:-default} interpolation, multiple handler backends (file, console, OTEL), and rotation. Hand-rolling a logging schema from scratch duplicates tested work.

Verification before marking work complete

  1. Run the code path and confirm log lines actually emit — don't assume.
  2. Pipe a log line through jq (or equivalent) to confirm it's valid JSON (or whatever your configured format is).
  3. State in the PR description which events you verified emit correctly.

Local vs. production output

Local/dev: human-readable (pretty / dev format, colorized). Production: machine-parseable JSON, no color codes. Configure this via an environment variable, not a code branch:

handlers:
  console:
    formatter: ${LOG_FORMAT:-json}   # override to 'pretty' in dev

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.