Claude Skills by snoodleboot-io

Share data between threads correctly: establish happens-before, prefer pools and higher-level constructs over raw threads, and know where virtual threads fit.

Threads do not automatically see each other's writes. The compiler, JIT, and CPU may reorder instructions and cache values in registers, so a write in one thread can be invisible to another indefinitely. The Java Memory Model defines *happens-before*: if action A happens-before action B, then A's effects are visible to B. You get those edges only through synchronization.

Predict the order JavaScript runs your code: one call stack, a microtask queue that drains fully first, and a macrotask queue behind it.

JavaScript executes on a single thread with one call stack. A function pushed onto the stack runs to completion before the engine does anything else — no timer, promise, or event handler can interrupt synchronous code partway. Concurrency comes from *scheduling* callbacks to run later, never from preemption.

Manage the lifecycle of encryption keys — generation, storage, rotation, revocation — so that a key compromise is survivable and rotation does not require re-encrypting the world.

The central pattern. Data is encrypted with a short-lived Data Encryption Key (DEK); the DEK is encrypted ("wrapped") by a Key Encryption Key (KEK) held in a KMS or HSM. Only the wrapped DEK is stored, next to the ciphertext.

Size, cap, and scale workloads so pods get the CPU and memory they need without starving the node.

Two numbers with two different audiences. `requests` talks to the **scheduler**: it reserves capacity and decides placement. `limits` talks to the **kernel**: it caps what the container may actually consume.

Decide whether to ship using criteria agreed before anyone was emotionally invested, and keep the ability to undo the decision cheaply.

The purpose of a readiness review is to produce a decision that could have gone the other way. Most reviews cannot: the criteria are phrased so that "yes" is the only grammatically available answer, and the meeting becomes a ritual performed on the way to a launch that was never in question.

Find where a system's latency curve bends, and why, rather than proving it passed a number someone invented in a planning meeting.

Most teams run one test — expected peak for ten minutes — and believe they have load tested. Each shape isolates a different failure mode, and the others stay invisible until production finds them.

Choose a managed database by the access pattern the data will actually see — not by which engine is most familiar or most talked about.

The most expensive database mistakes are made before a single row is written, by choosing the engine from familiarity or hype and then discovering the data does not fit. Invert it. Write down the access pattern first:

Create entity relationship diagrams using Mermaid syntax

Comprehensive guide for creating entity relationship diagrams using Mermaid syntax

Choose a messaging system by what your consumers need — delivery guarantee, ordering, retention, fan-out — not by brand familiarity.

Messaging systems fall into three fundamental shapes, and most bad choices come from reaching for a familiar product before deciding which shape the problem needs.

Choose how services talk to each other, given that every synchronous call adds latency and borrows the callee's availability.

Every synchronous call does two things beyond transferring data: it adds the callee's latency to yours, and it makes your availability the product of both.

Get a trained model serving traffic safely — packaged, versioned, and rolled out so a bad model is caught before it reaches every user.

A model in production is never just weights. It is a bundle whose parts must move together, because any one of them changing alters the predictions.

Design the automated path from raw data to a registered, deployable model — reproducibly, so any past model can be rebuilt from what you recorded.

Software CI assumes a git sha plus a lockfile determines the build. ML breaks that: the same commit trained on Tuesday's table and Thursday's table produces two different models, both labelled with the same sha.

Choose metrics that track the decision the model actually drives, and report them with enough uncertainty that a difference is believable.

Every metric encodes an opinion about which mistake hurts. Start from the decision the model drives, then pick the metric that penalizes the costly error.

Explain what a trained model is doing — globally and for individual predictions — without mistaking the explanation for a statement about the world.

"Make it interpretable" is four different requests. Separate them before choosing a tool.

Detect a model degrading in production before the business notices — despite ground-truth labels arriving days or weeks after the prediction.

The layers trade timeliness against definitiveness. Build them in this order, because the fast layers are what actually page you.

Diagnose why a model underperforms by isolating the cause — data bug, capacity limit, optimization failure, or irreducible noise — before changing anything.

Run this before anything else. It is the cheapest experiment in machine learning and it partitions the space of causes in one shot.

Decide whether to run across multiple cloud providers at all — and if so, at what coupling level — knowing that multi-cloud usually costs more than the lock-in it is meant to avoid.

"Multi-cloud" is a loose word that hides four distinct architectures with different costs. Most requests for multi-cloud are really requests for one of the cheaper cousins.

Run a genuinely-parallel multiagent implementation - plan, gate on environment, spawn subagents concurrently, aggregate

Run a genuinely-parallel multiagent implementation with detailed guidance - plan, gate on environment, spawn subagents concurrently, aggregate, and debug/retry

Test the tests: deliberately break the production code and check that some test notices.

Line coverage answers "did this line execute during the test run". That is a much weaker claim than "if this line were wrong, a test would fail" — and the second is the only claim anyone actually cares about. The gap between them is where escaped bugs live.

Choose a non-relational store by starting from the queries you must serve, not from the shape of your entities or a scale number you have not yet reached.

Relational modelling lets you defer query design: normalize the entities, and the optimizer will find a plan for whatever you ask later. Non-relational stores remove that safety net. There is no join and often no ad-hoc filter, so the physical layout *is* the query plan. Design it from the queries or you will discover, in production, that a required read is impossible without a full scan.

Use object storage (S3, GCS, Blob) for what it is — a flat, HTTP key-value store of immutable blobs — and stop treating it like a filesystem.

Almost every object-storage mistake comes from carrying filesystem instincts into a system that only superficially resembles one. Object storage (S3, GCS, Azure Blob) is a flat map from a string key to an immutable blob of bytes, reached over HTTP. That is the whole model. What looks like a directory tree is an illusion the tooling paints over a flat namespace.

Make a system measurably faster by finding where the time actually goes, rather than where you assume it goes.

The instruction to profile before optimizing survives because intuition about performance is unusually bad — worse than intuition about correctness. Code that *looks* expensive (a nested loop, a regex, a hand-rolled parser) is often trivial next to code that looks free (an ORM attribute access that lazily fires a query, a logging call that formats a large object at DEBUG level even though DEBUG is off).

Document follow-up work and testing needs after implementation

Comprehensive checklist for documenting follow-up work and testing needs after implementation

Turn a vague request into a tree of sub-problems that are individually measurable, independently solvable, and small enough to finish.

A stakeholder asks to make search faster. As stated this cannot be started, finished, or verified. Decomposition is the work of converting it into a tree whose leaves each have an owner, a size, and a number that says when they are done.

Instrument a product so the numbers survive contact with a real question — consistent names, stable definitions, and a source of truth you can bill against.

An analytics implementation degrades along a predictable path: it starts clean, each team adds events in their own style, and within a year nobody can answer a question without first asking three people what an event means. The taxonomy is what prevents that, and it only works if it is enforced in code review.