Add Structured Logging
Adds structured log lines with stable event names and join IDs to changed code paths.
Install
npx skills add ParadevAI/Paradev --skill add-logging -g -a claude-code -y- Repository
- ParadevAI/Paradev15.8k
- Category
- Engineering
- Updated
- 3d ago
- License
- See repository
- Context cost
- Lightabout 622 tokens
- Runs scripts
- No, instructions only
What it does
Before shipping a change, add structured log lines to the code path it touches so the next investigation has evidence, one line per decision and failure, with stable event names and the IDs needed to join requests, at the right level and without secrets. Use when writing or reviewing a feature or fix, when a bug was hard to diagnose because the logs were silent, or when the user asks to improve logging or observability in code.
Log what you will need to ask about
Every investigation in Sazabi is limited by what the code logged. The cheapest time to add the right lines is while the change is fresh. The job is a small number of structured lines that answer "what happened to this request, and why".
0. How the tools work
The Sazabi MCP server lists only two tools, search and execute. Browse
Sazabi's operations with search and namespace: "sazabi" (an empty query
without a namespace lists connected connectors, not Sazabi operations). Before
calling one, repeat search with namespace: "sazabi", the hit's full name as
the query, and includeInputSchema: true to load its arguments. Then run it
with execute as { name, arguments }, the name copied from the hit (for
example sazabi/logs.ask).
1. Match what is already there
Read how this repository logs: which logger, which field names, how request and
trace IDs are attached. Ask sazabi/logs.ask for a sample of this service's
recent lines to see the real shape. New lines must look like their neighbors;
an investigation that has to join two naming schemes is slower.
2. Pick the lines
On the changed path, log:
- Failures with the error, the input that caused it (IDs, not payloads), and what the code did next (retry, fallback, give up).
- Decisions that change behavior: a feature flag, a fallback, a skipped step, a limit hit.
- Boundaries: calls to other services or queues, with target, outcome and duration.
Skip lines that restate the obvious ("entering function").
