Hold your horses
Apply before surfacing a risk, defect, failure, or scary estimate to the user. Verify the concern with the cheapest available check FIRST, then lead with the measured verdict — not the raw worry. Use whenever you catch yourself about to raise an alarm you have not yet confirmed (walltime kills, data defects, contention, "this will fail / this is wasted / someone will grab X").From its SKILL.md
npx -y skills add AmitAminov/amit_aminov_skills --skill hold-your-horsesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.8 KB, 608 tokens by cl100k_base, as published. Nobody here has run it
hold-your-horses
The failure this prevents: flagging every risk the instant you spot it, then walking it back once you actually measure it. That reads as alarmism and rattles the user — especially first thing in the morning. In this project it happened three times in one morning ("38% of generations are empty", "a walltime kill wastes 48 h", "someone will grab the goldfish GPUs") — each defused by a check that took two minutes and should have come before the alarm, not after.
The rule
Measure before you alarm. Lead with the verdict, footnote the worry.
When you notice something that might be a problem and you're about to tell the user:
- Do the cheap check first. Almost every scare here is verifiable in one command:
- "Is it slowing down / will it miss walltime?" → parse the per-batch timestamps and project.
- "Is this a defect / data loss?" → look at the raw records / the code path, don't infer.
- "Will another job grab the resource?" →
squeue/scontrolthe actual competitors and their GPU type (H200 ≠ L40S). - "Did the fix work?" → grep the log for the error signature, count it.
- Then report the conclusion first. State what the measurement says. If the concern is dead, it may not need mentioning at all — or one line: "checked X, it's fine."
- Keep the raw worry as a footnote, only if it survives the check. If it's still live after measuring, say so plainly with the number attached ("finishes with ~3–6 h margin — tight but fits"), not as a naked "this might blow up."
What NOT to do
- Don't send "⚠ this might be a disaster" and then investigate in the next turn.
- Don't stack hypotheticals ("if it's killed, and if the resubmit loses the race, and…") before checking whether the first link is even real.
- Don't dress a snapshot as a trend (one slow batch ≠ "it's degrading") — get ≥3 points.
When to alarm immediately anyway
If a risk is both genuinely urgent AND not cheaply verifiable (irreversible action about to fire, external deadline, data about to be overwritten), flag it now — but label it explicitly as unverified and say what check you're running to confirm. Speed beats polish only when the check itself is the slow part.
One-line test before hitting send
"Have I measured this, or am I forwarding a hunch?" If it's a hunch and a command can settle it, run the command first.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.