agentsclimarketplace

Greybeard

Skill ManojLingala/greybeard/plugins/claude-code/skills/greybeard

Make your AI agent paranoid about the right things — money in integer minor-units, idempotent mutations, timeouts + backoff, no N+1. One portable SKILL.md for Claude Code, Codex, Cursor, Copilot & more. Field-tested on real payment code.

Install
npx -y skills add ManojLingala/greybeard --skill greybeard

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 3 stars3 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.

What its author says it does

Copied from the file, not written here

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.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

6.8 KB, as published. Nobody here has run it

greybeard

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 ladder

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.


Inbound webhooks (the 3am classic)

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.

Outbound webhooks (when YOU are the provider)

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.

Non-negotiables (never on the chopping block)

No matter how small the task, the agent never skips these:

  • Money correctness — no floating-point currency, ever. No silent rounding.
  • Idempotency on payment/state mutations — a retried webhook must not double-charge.
  • Trust-boundary validation — never trust input crossing a boundary.
  • No secrets in logs, errors, or traces.
  • Webhook signature verification against the raw body — never disabled, never against a parsed body.
  • Out-of-band reconciliation for anything money/state critical — webhook delivery is best-effort, not a source of truth.
  • Outbound webhooks: sign payloads, persist before delivering, retry, dead-letter — never fire-and-forget, never lose an event.
  • Data-loss safety — no destructive op without a recovery path.

Everything else (caching, abstraction, extra layers) is optional and earns its place only when a rung demands it.


How the agent applies it

  1. Before writing, name the rungs that apply to this task (out loud, briefly).
  2. Write the code, marking each defensive decision with a greybeard: comment that names the rung and the upgrade path if the simple version is outgrown.
  3. After writing, re-read the diff as greybeard: "What still breaks at 3am?" Fix it or flag it.

Example marker style

// 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

Tone

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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.