Reviews ONE piece of retry code, or a written retry design for an agent or a service client, and lists only the five mistakes that turn a failure into an outage or a double write, one line each with a fixed code, the place, why it hurts and the fix - or exactly No findings. It catches waits that grow without a random part, a loop with no limit on tries or on total time, a POST repeated with no idempotency key, a 429 or 503 answer whose Retry-After header is never read, and retries on client errors that cannot change. It leaves out the safe look-alikes, such as a GET retried with a cap and jitter, a retry set of 408, 429 and server errors only, and a wait taken straight from Retry-After. Use to review the retry loop of an API client, to audit how an agent calls tools that fail, or before shipping a client to production.
Retry Backoff Review is a tested SKILL.md that reviews ONE piece of retry code, or a written retry design for an agent or a service client, and lists only the five mistakes that turn a failure into an outage or a double write, one line each with a fixed code, the place, why it hurts and the fix - or exactly No findings; an agent buys it once for $0.01 over x402.
Not for
Circuit breakers, queue-based retries, library defaults and the server side of rate limiting. It reads one pasted piece of retry code or a short written design and judges only how a single failed call is repeated. It does not judge what the call does after the last try fails, nor how an agent decides to stop its whole run.
Tested, honestly
Tested 2026-10-26 with a strong and a weak model.
- SonnetStrong model, claude-sonnet-5-5
- Right on all 3 cases, read by hand. On the charge loop it gave the missing random part, the endless loop and the repeated POST to the charges endpoint, and left out the capped profile read with jitter that sits beside it. On the order sync it found the ignored Retry-After header and the retry of every client error, and left out the PUT, which is idempotent, and the jittered six-try loop. On the clean report fetch it answered exactly No findings, so the wait read from Retry-After and the single POST passed.
- HaikuWeak model, claude-haiku-5-5
- Right on all 3 cases, read by hand. It matched the strong model on both planted files, with fixes that name the exact line to change, and kept the capped read and the PUT out. On the clean fetch it answered exactly No findings. Its charge answer is longer than the strong model's but stays one line per code.
Full test summary
Example
Our own test text, before and after the skill ran. Excerpts only.
English · claude-sonnet-5-5
Before
import random, time, requests
def post_charge(payload):
delay = 1
while True:
r = requests.post(URL + "/charges", json=payload, timeout=10)
if r.status_code < 500:
return r
time.sleep(delay)
delay *= 2
def get_profile(user_id):
for attempt in range(5):
r = requests.get(f"{URL}/users/{user_id}", timeout=5)…
After
NO-JITTER — `post_charge`: `time.sleep(delay)` with `delay *= 2` — the wait grows by a fixed rule, so clients that failed together retry together — add a random part, e.g. `time.sleep(random.uniform(0, delay))`, and cap the delay at a maximum…
What is in the file
- What the public sources say, as read on 26 October 2026
- The answer
- The codes
- Rules
- Work in this order
- Short example
Languages
English. Tried in: English.
License
Perpetual, non-exclusive; use and modify for yourself incl. paid work; no resale or republishing. Holder: Georgi Kalchev, aiskills402.com. Full terms.
Versions
Current version 1.0.0, updated 2026-10-26. Whoever bought an earlier version gets new ones free through the same re-download token.
v1.0.0 · 2026-10-26
First release, written in the second light-test batch of 26 October 2026 (three cases, price $0.01). The idea is ours; no foreign skill was opened, facts come from public sources (see notes/ideas.md). Output: see the skill description.
Test: three cases written by hand (two planted, each with a safe look-alike, one clean control), one run on Claude Sonnet and one on Claude Haiku, no run without the skill, no iteration on the skill rules after the runs. `test/control.mjs` shows that the checks pass on the ideal answers and fail on realistic wrong ones. See `test-summary.json` for the verdicts read by hand.
FAQ
Statuses worth retrying: which ones?
Timeouts reported as 408, too-many-requests answers and server errors. That set is the skill's own policy, stated in its text, and a loop that retries a 404 or a 422 gets a line for it.
Does a PUT that is repeated get reported?
No. RFC 9110 lists PUT and DELETE as idempotent, so only a call that creates or changes something without such a guarantee, such as a plain POST, needs a key.
Which code did the trial use?
A Python charge loop that doubles its wait without end beside a capped, randomised read; a JavaScript order sync that ignores Retry-After and retries every 4xx; and a clean report fetch. Sonnet and Haiku saw each file once.
What does a sound retry loop earn?
The lone sentence No findings. Anything wrong appears on its own row instead: the code name, the spot in the paste, the harm done and the repair.