Consistent, Safe Application Logging
Adds structured, correlated logs with useful severity, safe fields, bounded volume, and targeted verification.
Before & after
Same prompt, same agent — the only difference is the skill.
You'll want to log important events in your payment flow. Standard practice is to log when things start, finish, and if errors occur. You might log to console or a file, and later stream to a logging service. There are different approaches to how detailed you want to be. It's worth thinking about what's useful to search for later when debugging.
POSTHOG STRUCTURED LOGGING FOR PAYMENTS
LOGGING PATTERN (PostHog event naming convention):
1. PAYMENT INITIATED
Event name: payment_method_selected
Properties:
• payment_method: string (card, bank_transfer, wallet)
• amount_cents: number
• currency: string (ISO 4217)
• user_id: string (hashed if PII)
• session_id: string (correlation ID across flow)
• timestamp: ISO 8601
• metadata: {billing_address_same_as_shipping: boolean}
2. PAYMENT PROCESSING
Event name: payment_processing_started
Properties:
• processor_id: string (Stripe ID)
• processor_response_code: string
• authorization_method: string (3DS, tokenized, etc)
• risk_score: number (0-100, if available)
• timestamp: ISO 8601
3. PAYMENT COMPLETED
Event name: payment_completed
Properties:
• transaction_id: string
• amount_cents: number
• fee_cents: number
• net_cents: number (amount - fee)
• status: string (captured, processing, requires_action)
• time_to_completion_ms: number
• timestamp: ISO 8601
4. PAYMENT FAILED
Event name: payment_failed
Properties:
• failure_reason: string (insufficient_funds, expired_card, rate_limit, etc)
• error_code: string (from processor)
• user_facing_message: string (customer-safe error text)
• retry_eligible: boolean
• retry_count: number
• timestamp: ISO 8601
IMMEDIATE SEARCHES:
• Debug: Trace single transaction via session_id
• Report: Revenue by processor in date range
• Alert: Failed payments >50 per hour
• Cohort: Users with 3+ payment failures
NOTE: Do not log full card numbers, expiry, or CVV. Do not log bank account numbers.About this skill
“We added logs, but I still can't tell what happened.” This skill makes application logs answer concrete debugging questions: which operation failed, what happened before it, whether it recovered, and how to find the related request. It applies consistent event names, severity, correlation, and field rules while keeping secrets and repetitive noise out.
What it does
- Adds logging through your existing logger, preserving the codebase's format and conventions.
- Designs stable events for operation outcomes, retries, dependency failures, and meaningful state changes.
- Carries request, trace, and job identifiers across asynchronous work without mixing concurrent requests.
- Separates expected rejections, recoverable failures, and exhausted operations so severity reflects the outcome.
- Reviews fields, exception output, and request metadata for sensitive data exposure.
- Checks event shape, duplicate errors, log volume, and whether logging failures can break application behavior.
What you get
A scoped implementation or review with an event contract, concrete code changes, representative structured records, and verification status. Small questions receive a direct fix; larger changes include the decisions needed to keep future logs consistent.
Best for
Product engineers and backend teams adding logs to features, debugging disconnected request histories, or cleaning up inconsistent and noisy application logging.
SKILL.md preview
---
name: consistent-safe-application-logging
description: >-
Implements and reviews structured application logging using stable event contracts, outcome-based severity, asynchronous correlation, explicit field allowlists, and volume controls. Use when the user says "add logs to this handler", "make our logging consistent", "my logs keep exposing request data", "I can't follow a request across services", "we get the same error five times", "our retry logs are too noisy", or "review these log statements".
---
# Consistent, Safe Application Logging
… (sign up to view the full skill)More development skills
View all Development skills →Production Go: Concurrency, Services & Profiling
Production Go code with leak-free goroutines, context-correct services, wrapped errors, and pprof-driven performance fixes.
Backend Feature Build Plan
Builds one backend feature through gates: confirmed requirements, one-screen design, small tested slices, and a deploy/rollback handoff.
Reliable WebSocket Messaging and Scaling
Build WebSocket and Socket.IO systems with authorized rooms, reconnect recovery, bounded queues, and multi-node presence.
Laravel App Build: Eloquent, Sanctum, Queues, Livewire
Laravel 12/13 code that ships: N+1-free Eloquent, correct Sanctum mode, idempotent queued jobs, lean Livewire, and Pest tests.