deepenlisted

# Skill: /deepen ## Purpose Add structured logging, metrics, and tracing to a specified module to make it debuggable and understandable in production. ## When to Use - A new module has shipped but has no logging — debugging requires guesswork - A bug was hard to reproduce because there was no trace of what happened - Code review flags a module as "too shallow" — no error context, no timing, no state logging - Before adding a complex feature to a module that currently has no instrumentation - When the user says "add logging to X", "make X debuggable", or "instrument X" ## Steps 1. **Resolve the target module.** If invoked with no argument, scan for modules with zero `logging.getLogger` calls and list the top 5 by line count. Ask the user to confirm which to instrument. 2. **Audit the module against the 9-symptom checklist.** The checklist below is written with Python's `logging` module as the example — map each symptom to the project language's structured-logging equivalent (e.g. `tracing`/`log` in Rust, `pino`/`winston` in Node). Read the file(s) and check each symptom: - [ ] No `logging.getLogger(__name__)` at module level - [ ] Exception handlers with bare `pass` or only `raise` (no log) - [ ] Functions longer than 40 lines with no log statements - [ ] External I/O (HTTP, DB, file, subprocess) with no timing or error logging - [ ] State transitions with no record (state changes silently) - [ ] Loop bodies that process collections with no count/summary