Measure Before You Fix

Convention: see conventions/brain-first.md, > before re-deriving a diagnosis, search the brain for prior incidents of the same alert. A recurring alert usually has a recorded verdict already.

Route here on any alert whose claim is temporal, "X is stale", "step timed out", "pipeline wedged", "job is slow", "N hours behind". These alerts invite an immediate structural fix (raise the timeout, split the step, reorder the pipeline). Do the measurement first. It is almost always cheaper than the fix, and it frequently invalidates it. (Routing is a harness convention, not a mechanical guarantee, the contract below is the discipline that makes it stick.)

On gbrain surfaces this covers: gbrain doctor staleness checks (e.g. sync freshness, cycle freshness), autopilot cycle alerts, the sync stall watchdog (reason: 'stall_timeout'), and any cron monitor built on top of them.

The rule

One stopwatch measurement of the suspect step, before any code change.

If you cannot state the measured duration of the thing you claim is slow, you do not yet know the root cause, and any fix you write is a guess wearing a diff.

Contract

This skill guarantees:

• No structural fix (timeout raise, step split, pipeline reorder, wrapper rewrite) is proposed before a measured duration of the blamed step exists.
• The measurement targets the specific entity the alert named, not the aggregate (--all hides which member is slow).
• The alert's threshold is compared against the authoritative one (gbrain doctor's warn/fail lines) before the system is declared unhealthy.
• The verdict explicitly distinguishes "needs more time" from "is wedged", they have opposite fixes.
• Read-only: this skill changes no timeouts, thresholds, or code. It produces a measurement verdict that sizes the fix; the fix itself is a separate, now-informed change.

Procedure