Observability Gate Skill

Code that cannot be observed in production is incomplete. It does not matter how well it works in staging. If it fails silently at 3am, the on-call engineer is blind. This skill enforces a minimum observability surface before any feature is considered done.

The Three Requirements

Every feature, endpoint, background job, or service must ship with all three of the following:

1. One structured log line A log entry at a meaningful event boundary (request received, job started, error encountered, state transition completed). It must be structured (key-value or JSON), not a string concatenation. It must include enough context to correlate with other logs (request ID, user ID, entity ID, or equivalent).

2. One metric emission A counter, gauge, or histogram that tracks the operation. The metric must have a name that matches the feature (not a generic requests_total that already exists). It must include at least one dimension or label that distinguishes this operation from others.

3. One named alert condition A written definition of what constitutes "this thing is broken." It does not need to be wired into PagerDuty right now. It must exist as a comment or stub that names: the metric to watch, the threshold, and the time window. Example: // ALERT: error_rate > 1% over 5 minutes → page on-call.

The Gate Check