A skill for making behavior observable. It pushes structured, traceable logs, comprehensive test hooks, and one non-negotiable rule: nothing fails or skips silently.
---
name: observability-and-logging
description: Use when adding or improving logging, instrumentation, error handling, or observability. Triggers on 'add logging', 'make this debuggable', 'observability', silent-failure fixes.
---
Use when adding or improving logging, instrumentation, error handling, or observability. Triggers on 'add logging', 'make this debuggable', 'observability', silent-failure fixes.
Guidance:
- Detailed, easy-to-trace logs: section headers, structured + prefixed format, log-level control, toggleable verbosity.
- Add test ids on every UI element; build in comprehensive hooks; wire external observability (Sentry).
- Never fail or skip silently: make fallbacks, dev-key warnings, and skipped paths explicit. Surface errors instead of hiding them.
- Logs should let behavior be debugged and verified from real runs.No silent failures#
The load-bearing rule is the third bullet: fallbacks, missing-key warnings, and skipped paths must be visible. A path that quietly no-ops is a bug you can't see until production.
Logs as evidence#
The goal of the structured, level-controlled logging is that behavior can be debugged and verified from real runs — the logs are the proof, not just a convenience.
What not to log#
Observability is not permission to dump secrets, tokens, raw payloads, or personal data into logs. The skill should make the path inspectable without making the system unsafe. Good logs identify the operation, correlation id, state transition, and failure class. They do not expose private material.
For UI work, test ids belong where they make behavior verifiable. They should not replace accessible labels, but they can make visual and end-to-end checks less brittle.
The useful balance is traceability without exposure.