measure-before-you-fix

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

Updated Aug 17, 2026
One-click install
npx skills add https://github.com/AMC-JTC/gbrain-1 --skill measure-before-you-fix-amc-jtc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: measure-before-you-fix
Source: https://github.com/AMC-JTC/gbrain-1/tree/main/plugin/skills/measure-before-you-fix
Command: npx skills add https://github.com/AMC-JTC/gbrain-1 --skill measure-before-you-fix-amc-jtc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Temporal alerts like "sync is stale", "job timed out", or "pipeline wedged" invite immediate structural fixes — raising timeouts, splitting steps, rewriting wrappers — that are often wrong because nobody measured the actual step. This Skill enforces a measure-first discipline so you kill the theory with a stopwatch instead of a code change. ## Core Features & Use Cases - Stopwatch-first triage: Times the exact entity named in the alert (e.g. time gbrain sync --source source-a --no-embed) rather than the aggregate, so the real bottleneck is isolated. - Threshold mismatch detection: Compares the monitor's act-line against the authoritative gbrain doctor warn/fail lines to catch false pages on healthy systems. - Verdict-driven fixes: Produces a structured measurement verdict distinguishing "needs more time" from "is wedged" — two states with opposite fixes. - Use Case: A cron monitor pages repeatedly that two sources are 14 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 alert threshold in two lines instead. ## Quick Start Ask the agent to triage the freshness alert by measuring the 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 do when a sync job keeps timing out?

Measure the step directly first to distinguish "needs more time" from "is wedged", since they have opposite fixes. Raising a timeout on a genuinely hung step just makes it hang longer.

Why does my cron monitor keep paging about a system that looks healthy?

The monitor is likely alerting at its act-threshold, which sits below the authoritative warn line from `gbrain doctor`. Separate the constants: act early, but alert at the doctor's warn line.

Does this skill change timeouts or thresholds automatically?

No. It is read-only and produces a measurement verdict that sizes the fix. Any timeout, threshold, or pipeline change is a separate, now-informed change made afterward.

When should I use a debugging skill instead of measure-first triage?

Use systematic debugging for code behavior problems like wrong output or 500 errors. Use measure-first triage for temporal ops alerts; if the stopwatch confirms genuine slowness, hand off to debugging with the measured number.