better-logging — Claude Code skill: logging and setup
This skill turns key runtime operations into queryable outcome records. Use it when scattered logs make failures, latency, or regressions hard to trace.
npx skills add biw/skills --skill better-logging -a claude-codeWhat better-logging does
better-logging treats an operation boundary as the unit of instrumentation. It covers HTTP handlers, tRPC procedures, IPC commands, queue consumers, cron jobs, startup actions, and background work. A record begins at entry, gains context during execution, and is finalized in finally, so both successful and failed runs produce an outcome.
The package includes scripts/audit_queryable_outcomes.py, which scans a repository for operation boundaries, correlation fields, and existing durable signals. references/event-schema.md defines the event shape, while separate references cover Electron and Node runtimes. references/rollout-and-queries.md describes how to test the resulting data. Missing request_id, operation_id, or session_id weakens every later query.
The skill recommends a local table, operational event store, or queryable analytics sink instead of ephemeral console output. Secrets, tokens, raw prompts, and unnecessary URL data should be redacted or hashed. Start the audit with python3 scripts/audit_queryable_outcomes.py --root . --format markdown.
What it helps with
- map operation boundaries across a repository
- capture success and failure in one durable event
- add duration, retry count, and stable error codes
- test whether events answer failure and latency questions
Example prompts for the agent
- Audit this repository and identify the HTTP handlers, queue consumers, and startup flows that need instrumentation.
- Design an event schema for the payment operation and wrap it so the outcome is persisted from
finally. - Review the current events and check whether they support failure, latency, and regression queries.
How to install better-logging
1Skills CLI (Vercel)
npx skills add biw/skills --skill better-logging -a claude-code2Manually: put the files in place
~/.claude/skills/better-logging/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/better-logging/
1Skills CLI (Vercel)
npx skills add biw/skills --skill better-logging -a codex2Manually: put the files in place
.agents/skills/better-logging/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add biw/skills --skill better-logging -a cursor2Manually: put the files in place
.cursor/skills/better-logging/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install biw/skills better-logging2Manually: put the files in place
.github/skills/better-logging/SKILL.md1Skills CLI (Vercel)
npx skills add biw/skills --skill better-logging -a gemini-cli2Platform CLI
gemini skills install https://github.com/biw/skills --path skills/better-loggingManually: put the files in place
.devin/skills/better-logging/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add biw/skills --skill better-logging -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about better-logging
How do I install better-logging in Claude Code?
Run npx skills add biw/skills --skill better-logging -a claude-code, then open ~/.claude/skills/better-logging/SKILL.md.
What does better-logging do?
It guides the design of durable, structured outcome events for important runtime operations. The records can include duration, success, stable error codes, and correlation IDs.
What resources come with better-logging?
It includes scripts/audit_queryable_outcomes.py, an event-schema reference, runtime patterns for Electron and Node, and a rollout guide with query checks.
Source text
SKILL.md · MIT
--- name: better-logging description: Design durable, queryable operation outcome events for HTTP, IPC, tRPC, jobs, startup flows, and queues so failures and latency are easy to investigate. metadata: source: "biw/skills" homepage: "https://github.com/biw/skills" --- # Better Logging Turn important operations into durable structured records that answer "what happened?" with one query instead of a trail of log lines. Treat the unit of instrumentation as an operation owned by the runtime, not as individual log statements sprinkled through the codebase. ## Quick Start - Run the audit script first: ```bash python3 scripts/audit_queryable_outcomes.py \ --root . \ --format markdown ``` Run the bundled `scripts/audit_queryable_outcomes.py` from this skill directory. If needed, resolve the directory containing this `SKILL.md` and pass the script path explicitly. - Read exactly one runtime reference before changing code: - Electron, tRPC, IPC, background desktop jobs: `references/runtime-patterns-electron.md` - Node HTTP apps and workers: `references/runtime-patterns-node.md` - Use `references/event-schema.md` to define the canonical event shape before writing middleware or wrappers. - Instrument the top 3 user-critical operations first. Do not start with every route or command in the repo. ## Workflow 1. Inventory operation boundaries. Transport boundaries usually matter most: HTTP handlers, tRPC procedures, IPC commands, queue consumers, cron jobs, startup flows. Treat low-level helper functions as enrichment points, not as the canonical operation. 2. Choose the operation record shape. Read `references/event-schema.md`. Lock required fields first: operation name, type, timestamps, duration, success, stable error code, correlation ID, version metadata. 3. Add one wrapper at the boundary. Start the record at entry. Enrich while the operation runs. Finalize and persist in `finally` so success and failure paths both emit an outcome. 4. Add domain context that improves debugging. Include actor, resource, trigger, rollout flags, retry count, and version data when available. Omit fields that are only interesting for local debugging or that contain secrets. 5. Persist or emit the result durably. Prefer a local table, operational event store, or queryable analytics sink. Do not rely on ephemeral console logs or in-memory buffers for critical outcomes. 6. Verify with real questions. Read `references/rollout-and-queries.md`. If the new shape cannot answer failure, latency, and regression questions quickly, the instrumentation is still too thin. ## Runtime Selection - Electron desktop app: Read `references/runtime-patterns-electron.md` for tRPC mutations, `ipcMain.handle`, startup actions, and background jobs. - Node server or worker: Read `references/runtime-patterns-node.md` for Express, Fastify, Hono-style handlers, queues, and cron jobs. ## Guardrails - Prefer one durable outcome event per important operation over many scattered log lines. - Keep `error_code` stable and machine-queryable. Treat free-form messages as secondary. - Record durations and retry counts on every critical operation. - Add correlation fields early. A missing `request_id`, `operation_id`, or `session_id` weakens every downstream query. - Separate operational truth from product analytics. Mirroring is fine; substitution is not. - Redact or hash secrets, tokens, raw prompts, user content, and full URLs when they are not strictly required. - Do not emit giant blobs by default. Persist pointers or summarized context instead. ## Resources - `scripts/audit_queryable_outcomes.py` Scan a repo for likely operation boundaries, existing instrumentation, correlation fields, and durable outcome signals. - `references/event-schema.md` Required and recommended fields, naming guidance, and redaction rules. - `references/runtime-patterns-electron.md` Boundary choices and wrapper patterns for Electron, tRPC, IPC, startup flows, and background jobs. - `references/runtime-patterns-node.md` Boundary choices and wrapper patterns for HTTP apps, queue consumers, and cron jobs. - `references/rollout-and-queries.md` Retrofit plan, acceptance checklist, and example questions the new instrumentation must answer.
© biw · MIT · biw/skills