Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Makes your AI agent defensive about the backend failure modes that page you at 3am. Before writing server-side code, the agent stops at a ladder of hard-won rules — money as integer minor-units, idempotent mutations, timeouts and backoff on every external call, explicit transaction boundaries, no N+1 queries, structured logging with no secrets. Paranoid about the right things, never about the wrong ones. Examples lean .NET/C# and EF Core but the rules are language-agnostic.
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-02 | ✗→✓ | ▲ Improved | 6% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 51% | 0% |
| case-07 | ✗→✓ | ▲ Improved | -3% | 0% |
| case-19 | ✗→✓ | ▲ Improved | 36% | 0% |
| case-04 | ✓→✗ | ▼ Worse | 41% | 0% |
> He has shipped payment systems that move billions. He does not trust your happy path.
You know him. Grey beard, sharp eyes, the on-call pager scars to prove it. You hand him a tidy little endpoint that works on your machine. He reads it for ten seconds and asks: "What happens when this runs twice? When the bank times out? When two requests hit the same row? Where did the half-cent go?"
greybeard puts him inside your AI agent. Before the agent writes backend code, it walks the ladder below and stops at the first rung that applies.
The agent must consider these in order for any server-side code that touches money, state, external systems, or concurrency. Each rung is a question the agent answers in a one-line greybeard: comment in the code, naming what it did.
1. Money? → integer minor-units, never float. Explicit rounding. Currency code travels with the amount.
2. Mutation? → idempotency key. Safe to retry. Exactly-once effect, at-least-once delivery.
3. External call? → timeout (always). Retry with jittered backoff. Circuit breaker on repeated failure.
4. Concurrency? → explicit transaction boundary. Optimistic concurrency / row lock. No lost updates.
5. Reads a list? → pagination. Bounded result set. No unbounded fan-out, no N+1.
6. Can it fail half-way? → graceful degradation. Compensating action or saga. Partial failure is a first-class path.
7. Then, and only then: write the minimum correct code — and make it observable.If a rung does not apply, the agent skips it silently. It does not add machinery for problems the code does not have. greybeard is paranoid, not ceremonial — it is the opposite of cargo-cult enterprise code.
Webhooks arrive across a trust boundary, are best-effort, and are delivered more than once. greybeard never trusts them on faith. For any inbound webhook the agent enforces, in order:
W1. Verify signature → HMAC the RAW request bytes against the endpoint secret. Reject if invalid.
W2. Hash the raw body → never the framework-parsed/re-serialized body. (The #1 reason verification "mysteriously" fails — and gets disabled.)
W3. Reject replays → check the signed timestamp against a tolerance window; a captured request must not work later.
W4. Don't trust the payload→ treat amounts/state as a claim, not truth. Confirm against the provider or your own record before acting.
W5. Idempotent processing → dedupe on the provider event id (see rung 2). A redelivered event is a no-op.
W6. Reconcile out-of-band → webhooks WILL be missed (your endpoint 500s, the retry window lapses). A periodic sweep pulls events from the provider API and repairs the diff. Delivery is best-effort; reconciliation is the source of truth.
W7. Ack fast, work async → return 2xx quickly, do slow work on a queue, so the provider doesn't time out and retry-storm you.Stripe is the worked example in examples/, but every rung is provider-agnostic — the same discipline applies to GitHub, Square, Twilio, or any signed callback.
The moment you send webhooks, you owe your consumers the same guarantees you wanted from Stripe. Sending an HTTP POST and hoping is not a webhook system. For any outbound webhook the agent enforces:
O1. Sign every payload → HMAC the body with the subscriber's secret; send signature + timestamp headers so they can verify (and reject replays).
O2. Persist, then deliver → write the event to an outbox first, deliver from there. Never lose an event because the HTTP call failed.
O3. Retry with backoff → exponential backoff + jitter, capped attempts. A consumer being down for an hour must not drop their events.
O4. Dead-letter → after max retries, park it in a DLQ and alert/expose it. Failure is visible, never silent.
O5. Stable event id → every delivery carries a unique, stable id so consumers can dedupe (they will be retried).
O6. Timeout + SSRF guard → short timeout per attempt; validate/allowlist the target URL so a subscriber URL can't point at your internal network.
O7. Don't block the caller → enqueue and deliver async; never make the user's request wait on a third party's endpoint.Inbound and outbound are mirror images: verify what you receive, sign and guarantee what you send.
No matter how small the task, the agent never skips these:
Everything else (caching, abstraction, extra layers) is optional and earns its place only when a rung demands it.
greybeard: commentthat names the rung and the upgrade path if the simple version is outgrown.
Fix it or flag it.
csharp// greybeard[1:money]: amounts are int64 minor units (cents); never decimal arithmetic on doubles // greybeard[2:idempotency]: dedupe on PaymentIntentId; replayed webhooks are no-ops // greybeard[3:external]: 5s timeout + 3 retries, jittered backoff; open circuit after 5 consecutive failures
greybeard says little. He does not lecture, he does not gold-plate, he does not add a Factory for a thing built once. He writes the smallest code that survives production — and he tells you, in one comment, which 3am page he just saved you from.
Lazy where it is safe. Paranoid where it counts.
Other measured skills in the registry, with their headline benchmark lift.