Generates logging instrumentation from log-review findings or for uninstrumented code. Use after log-review or when adding observability to a module.
Adds logging instrumentation to code that lacks observability. Takes log-review findings and implements the fixes — adding structured logging, error context, correlation IDs, and API boundary logging. Like test-gen for tests, but for observability.
This skill exists because adding logging is tedious but critical, and LLM-generated code almost never includes adequate logging on its own.
| Input | Source | Required |
|---|---|---|
| log-review findings | Artifact DB or direct scan | Yes (or target files) |
| project-context.md | Project root | Yes |
| Logger configuration | Project root | Recommended |
| Target files | User-specified or from findings | Yes |
Finding the input: Check the artifact DB first:
source artifacts/db.sh
db_read 'log-review' 'findings' 'standalone'
If no findings exist, ask the user to run /log-review first, or accept a list
of target files to instrument directly.
src/lib/logger.ts, app/core/logging.py)Read project-context.md to understand:
Check if the project already has a logger configured:
Node.js/TypeScript: Look for winston, pino, bunyan, morgan in package.json
Python: Look for logging, structlog, loguru imports
Go: Look for log/slog, zap, logrus, zerolog imports
Java: Look for slf4j, log4j, logback in dependencies
Rust: Look for tracing, log, env_logger in Cargo.toml
If no logger exists, create a minimal structured logger setup using the idiomatic library for the language. Prefer structured/JSON loggers:
Read log-review findings (from DB or user input). Group by category:
Present the grouped findings to the user and ask which to implement.
For each approved finding, implement the logging fix:
Silent failures: Replace empty catches with proper error logging:
// Before
catch (e) {}
// After
catch (e) {
logger.error({ err: e, operation: 'fetchUser', userId }, 'Operation failed');
throw e; // or handle gracefully with logging
}
Error context: Add structured context to error logs:
# Before
except Exception as e:
logger.error(f"Failed: {e}")
# After
except Exception as e:
logger.error("operation_failed", operation="fetch_user", user_id=user_id, exc_info=True)
API boundaries: Add middleware or interceptors for request/response logging.
Correlation IDs: Add request ID middleware that generates and propagates IDs.
Key rules:
After implementing:
This skill can be invoked from:
/review-fix — when log-review findings are part of a meta-review synthesis, review-fix can dispatch log-gen to implement logging fixes/meta-execute — during implementation, log-gen can be run as a post-generation pass to add logging to newly written code/log-gen directly after /log-reviewUser: [after log-review] "Fix the logging gaps"
→ Parse log-review findings from DB. Present grouped findings. Implement approved fixes.
User: "Add logging to src/api/routes/"
→ No prior findings needed. Scan the target directory for logging gaps, then instrument.
User: "We need structured logging throughout the project"
→ Create logger setup if missing. Scan for console.log/print statements. Replace with structured logger calls.
User: "Add correlation IDs to our API"
→ Focus on §4 correlation ID implementation. Add request ID middleware and propagation.
Before completing, read and follow ../references/cross-cutting-rules.md.