debug-logs

Diagnose browser, proxy, and WebSocket issues with DEBUG() runtime logging.

182|19|Updated Mar 23, 2026
One-click install
npx skills add https://github.com/adam-s/intercept --skill debug-logs-adam-s
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: debug-logs
Source: https://github.com/adam-s/intercept/tree/main/.claude/skills/debug-logs
Command: npx skills add https://github.com/adam-s/intercept --skill debug-logs-adam-s

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Iterative debugging with targeted logs. Use when browser connections fail, traffic capture returns empty, proxy routes return errors, WebSocket issues, or any problem that can't be solved on the first attempt. Add logs, read output, narrow the search, repeat until fixed, then clean up.

Core Features & Use Cases

  • Canonical DEBUG() functionality with separate server/API and client contexts to control observability.
  • Deferred evaluation via a factory function to avoid expensive computation when logging is disabled.
  • Flexible call signatures supporting simple messages, location tagging, and value objects for lazy evaluation.
  • Output to /tmp/interceptor-debug and console (cyan) for quick visibility.
  • Structured debugging workflow: hypothesize, instrument targeted logs, reproduce, read logs, and iterate across code paths such as HTTP, WebSocket, and UI interactions.

Quick Start

Enable DEBUG in your code, place targeted DEBUG() calls at suspected points, reproduce the issue, and read the logs under /tmp/interceptor-debug.

Frequently Asked Questions about debug-logs

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

FAQPage Schema
How do I add targeted logs to debug WebSocket connection failures in a browser?

Targeted runtime logging exposes internal state during iterative debugging. You instrument suspected code paths with DEBUG() calls, reproduce the issue, and read the output to narrow down browser, proxy, or WebSocket failures when traditional logs fall short.

What is the structured workflow for iterative debugging with targeted logs?

The structured workflow involves hypothesizing the error source, instrumenting targeted DEBUG() calls, reproducing the issue, reading the logs, and iterating. After fixing the problem, you clean up the temporary debug logs to maintain code hygiene.

How do I prevent expensive computations from running when runtime logging is disabled?

Runtime logging prevents expensive computations through deferred evaluation via a factory function. It supports lazy evaluation by accepting value objects, ensuring complex logic only executes when logging is explicitly enabled by the environment.

Can I use this targeted logging approach for both client-side browser and server-side API contexts?

Yes, targeted logging provides canonical DEBUG() functionality with separate server/API and client contexts to control observability. This allows you to independently enable or disable diagnostics across different client-server interaction layers.

When should I use targeted DEBUG() calls instead of traditional console logs for network issues?

Use targeted DEBUG() calls when browser connections fail, traffic capture returns empty, proxy routes error, or WebSocket issues persist after a first attempt. It enforces log placement guidelines and environment-based enablement for temporary diagnostics.