log-driven-debugging

When the bug is slippery, stop guessing and build observability.

This skill is for situations where:

• the visible symptom is known, but the actual failure layer is not
• static code reading is no longer enough
• one execution with good logs can collapse a large search space

The workflow is simple:

1. decide where to instrument
2. add high-signal logs
3. have the user rerun the scenario
4. analyze the returned logs
5. only then propose or implement the real fix

First move

Before adding any logs, ask the user for a log prefix.

This is required, not optional. Explain why briefly: the prefix makes the new logs searchable and prevents them from being lost in normal application output.