log

Standardize structured application logging with Pino-shaped APIs and FakeLogger assertions.

Updated May 7, 2026
One-click install
npx skills add https://github.com/johinsDev/loyalty-app --skill log-johinsdev
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: log
Source: https://github.com/johinsDev/loyalty-app/tree/main/.claude/skills/log
Command: npx skills add https://github.com/johinsDev/loyalty-app --skill log-johinsdev

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents scattered, inconsistent logging and makes logs testable and extensible across every app and package in the monorepo.

Core Features & Use Cases

  • Single logging abstraction: Use one consistent API for Pino-backed structured logs with built-in console and silent channels.
  • Scoped context via child(): Attach request/job/tenant identifiers without mutating shared loggers.
  • Deterministic testing: Use logManager.fake() to capture records and assert on levels, messages, bindings, and errors.

Quick Start

Use the log manager exported by your app bootstrap module and log structured events using bindings (objects) and messages (strings) instead of console.log.

Frequently Asked Questions about log

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

FAQPage Schema
How do I standardize structured logging across a monorepo with tRPC and Next.js?

Standardize structured logging by using a process-wide LogManager singleton with swappable channels, providing a consistent Pino-shaped API for tRPC, Next.js route handlers, and server actions. This prevents scattered, inconsistent logs across your services and packages.

How can I test application log output in unit and integration tests?

Test application log output deterministically by using the logManager.fake() method to capture records. This FakeLogger implementation allows you to assert on log levels, messages, bindings, and errors without relying on actual console output.

What is the best way to attach request and tenant identifiers to structured logs?

Attach request and tenant identifiers to structured logs using the child() method for scoped context. This allows you to attach specific bindings to log records without mutating shared logger instances across different requests or jobs.

Does this structured logging approach work with background job runners like Trigger.dev?

Yes, this structured logging approach explicitly supports Trigger.dev jobs. The LogManager abstraction applies consistently across request handling, server actions, and background jobs, ensuring uniform observability and context scoping throughout your asynchronous workflows.

Can I use Pino APIs for bindings and errors with this logging standardization?

Yes, you can use Pino-shaped APIs for bindings and errors. The logging abstraction provides a single consistent API built on Pino-backed structured logs, featuring built-in console and silent channels for flexible output management.

Why do I need a process-wide LogManager singleton for monorepo logging?

You need a process-wide LogManager singleton to centralize logging configuration and enable swappable channels. This ensures all packages and services in the monorepo query, test, and extend logs consistently without scattered or conflicting logger instances.