measure-before-you-fix

Diagnoses temporal ops alerts by timing the blamed step before proposing timeout or pipeline changes.

29.4k|4.4k|Updated Apr 5, 2026
One-click install
npx skills add https://github.com/garrytan/gbrain --skill measure-before-you-fix
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: measure-before-you-fix
Source: https://github.com/garrytan/gbrain/tree/main/plugin/skills/measure-before-you-fix
Command: npx skills add https://github.com/garrytan/gbrain --skill measure-before-you-fix

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Stale, timeout, freshness, and wedged alerts invite immediate structural fixes — raising timeouts, splitting steps, rewriting pipelines — before anyone has measured the step being blamed. This Skill enforces a measure-first discipline so fixes are sized against real numbers instead of theories.

Core Features & Use Cases

  • Stopwatch-first triage: Times the specific entity named in the alert (e.g. time gbrain sync --source source-a --no-embed) rather than the aggregate, and cross-checks state with gbrain sources status.
  • Threshold reconciliation: Compares the monitor's act-line against gbrain doctor's authoritative warn/fail lines (24h/72h defaults, env-overridable) to catch false pages on healthy systems.
  • Verdict classification: Distinguishes "needs more time" from "is wedged" — opposite conditions with opposite fixes — and produces a structured measurement verdict before any fix is proposed.
  • Use Case: A cron monitor pages repeatedly that two sources are hours stale. Instead of rewriting the sync wrapper, you time the sync directly, find it completes in seconds with "Already up to date", and fix the monitor's alert threshold in two lines.

Quick Start

Ask the agent to triage the freshness alert by measuring the blamed sync step before changing any timeout or threshold.

Frequently Asked Questions about measure-before-you-fix

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I triage a stale data or freshness alert before changing timeouts?

Time the specific step the alert blames, for example `time gbrain sync --source source-a --no-embed`, and compare the measured duration against the configured timeout. Only design a fix after you have that number.

What should I check when a cron monitor keeps paging about stale syncs?

Compare the monitor's alert threshold against gbrain doctor's authoritative warn line (24h warn, 72h fail by default). A monitor speaking below the doctor's warn line generates false pages on a healthy system; separate the act-threshold from the alert-threshold.

Should I raise the timeout when a gbrain sync job keeps timing out?

Not before measuring. If the step is genuinely hung, a bigger timeout just hangs longer. Measure the step first to distinguish "needs more time" from "is wedged", since those have opposite fixes.

Does this Skill modify timeouts, thresholds, or pipeline code?

No. It is read-only: it runs measurements and produces a verdict that sizes the fix. Any timeout change, threshold adjustment, or pipeline rewrite is a separate, now-informed change made afterward.

When should I use investigate or maintain instead of measure-first triage?

Use investigate for root-causing code behavior bugs like wrong output or 500 errors, and maintain for running brain health checks and repairs. Use this Skill specifically when a temporal ops alert pages and no measurement of the blamed step exists yet.