Claude Skills by snoodleboot-io

Choose an access-control model — RBAC, ABAC, or ReBAC — and enforce it in one place that no code path can route around.

RBAC assigns permissions to roles and roles to subjects. The discipline that keeps it maintainable is that application code asks about *permissions*, never about role names.

Match capacity to demand automatically, on a signal that actually tracks load, without flapping or starving requests during the ramp.

Every autoscaling decision is driven by one of three trigger types, and mature systems layer them rather than choosing one.

Choose between precomputing predictions on a schedule and computing them per request — a decision driven by how fresh the *inputs* must be, not by how modern the architecture looks.

The choice is not about scale or sophistication. It is about whether the model's inputs can change between the moment you would precompute and the moment the prediction is used.

Cut the cloud bill through the levers that actually move it — right-sizing, commitment discounts, storage tiering, killing idle resources, and controlling egress — not by micro-optimizing individual line items.

Almost every cloud estate is over-provisioned. Instances are sized from a guess, a worst-case peak that never materializes, or a copy-pasted template, and then never revisited. The result is a fleet running at a fraction of its paid capacity. Right-sizing — matching provisioned resources to measured usage — is the lever with the most headroom, and it compounds with every other technique, so it comes first.

Grant each identity the least authority it needs, from short-lived credentials, so that a single compromised identity cannot become a full breach.

Least privilege is easy to state and hard to hold: grant each identity only the permissions it needs to do its job, and nothing more. The reason it matters is not tidiness — it is **blast radius**. Every credential eventually leaks or is misused; the only question the design controls is how much damage the holder of a leaked credential can do. A role scoped to read one bucket is a minor incident when it leaks. A role with `*` is a company-ending one.

Move workloads to the cloud with a per-application decision, sequenced to reduce risk — not one big-bang rewrite of everything at once.

There is no such thing as "the migration." An estate is a collection of applications, and each one gets an independent disposition. The industry-standard framing is the six R's, and the discipline is to inventory every workload and assign one — with a reason — rather than applying a single strategy to everything.

Lay out VPCs, subnets, routing, and private connectivity so traffic reaches only what it should — without paying a fortune to cross an availability-zone boundary.

A VPC is a private IP space you own inside a region. Everything else — routing, isolation, egress control — is built from how you subdivide it. Two rules pay off for years: choose a CIDR big enough that you never renumber, and never let two networks you might one day connect share an address range.

Choose a primary cloud by comparing the primitives and managed services you will actually use, weighting your team's existing skills and data gravity far above any feature-count comparison.

Compute, object storage, block storage, a managed relational database, a message queue, a load balancer, a CDN — every major provider has all of these, and they are close enough in capability that comparing them line by line is wasted effort. If your architecture only uses the commodity layer, the choice is dominated by price, region availability, and what your team already knows.

Review code so defects are caught early and the author is unblocked fast — the second half is what most teams get wrong.

The single highest-leverage convention in code review is prefixing every comment with its severity. Without it, the author must reverse-engineer your intent, and the safe default is to treat everything as blocking — which is how a two-nit review turns into another round trip.

Work out where you can win rather than cataloguing what everyone else shipped — and remember that the thing beating you is usually a spreadsheet, not a rival.

Ask a team to name their competitors and you get three funded startups they read about on Hacker News. Ask their lost prospects what they chose instead and you get a very different list.

Measure honestly where your systems stand against a framework's control intent, so remediation is planned from evidence rather than discovered during an audit.

Scope is the first and most consequential decision in an assessment. It determines which systems an auditor examines, how much evidence you must produce, and how long remediation takes. Get it wrong in either direction and the assessment fails: too narrow and it collapses when the auditor traces a data flow you excluded; too broad and you spend a year evidencing systems that never touch regulated data.

Make controls prove themselves continuously — checked by code, evidenced by machines — instead of reconstructing a year of assurance in the four weeks before an audit.

The annual compliance scramble exists because controls are tested once, by hand, shortly before the auditor arrives. That model fails on its own terms: period-based reports and certifications ask whether the control operated *throughout* the window, and a test performed in week 50 says nothing about weeks 1 through 49.

Build a component library whose API survives contact with real product work, so feature teams stop reinventing buttons and forking styles.

A design system has three token layers, and conflating them is what makes systems impossible to retheme.

Reduce what a container can do and what it contains, so that code execution inside it yields as little as possible.

A container image is an attack surface you chose. Every binary in it is a tool available to whoever gets code execution — `curl` to stage a payload, `apt` to install one, a shell to run it interactively.

Turn incidents, delivery friction, and retro complaints into tracked changes that measurably move a number — instead of into documents nobody reads twice.

The purpose of a postmortem is to change the system, and that only works if people tell you what actually happened. Blame destroys that input directly: an engineer who expects to be named for a mistake reports incidents later, describes them more cautiously, and omits the detail that would have explained the failure. The cost is not abstract — it shows up as longer detection times on the next incident.

Estimate how a model will perform on data it has not seen, without letting information from the validation fold leak into training.

Cross-validation only estimates generalization if the split mimics the gap between training data and deployment data. Pick the splitter from the structure of the data, not from habit.

Choose the right cryptographic primitive for a job, and use it with the parameters that make it safe. Never design your own.

Cryptography rarely fails at the primitive — it fails at the seams, in how the pieces are wired together. Name the property you need, then pick the primitive that provides exactly that.

Write async code that doesn't deadlock, and LINQ queries that run once, in the right place (in memory vs. in the database).

`await` does not block a thread. It registers the rest of the method as a continuation, returns control to the caller, and resumes when the awaited task completes. The thread is free to do other work in the meantime — that is the whole point of async I/O.

Keep style and layout work off the main thread so scrolling and animation hold 60fps, and stop CSS from blocking first paint.

Every visual change enters the pipeline at one of four stages, and the stage determines the cost:

Essential questions to ask before designing a data model

Comprehensive process for discovering and validating data model requirements before design

```sql CREATE TABLE orders ( order_id INT, customer_id INT, amount DECIMAL ) PARTITION BY RANGE (YEAR(created_at)) ( PARTITION p2024 VALUES LESS THAN (2025), PARTITION p2025 VALUES LESS THAN (2026), PARTITION p2026 VALUES LESS THAN (2027) ); ```

**Monthly Partitions:** ```sql CREATE TABLE events ( event_id BIGINT, user_id INT, event_time TIMESTAMP ) PARTITION BY RANGE (YEAR_MONTH(event_time)) ( PARTITION p202601 VALUES LESS THAN ('202602'), PARTITION p202602 VALUES LESS THAN ('202603'), PARTITION p202603 VALUES LESS THAN ('202604'), PARTITION p_future VALUES LESS THAN MAXVALUE ); ```

Catch bad data at the point it enters your system, so downstream tables, dashboards, and models fail loudly instead of quietly producing wrong numbers.

A validation *boundary* is any point where data crosses from a system you do not control into one you do: an HTTP response, an S3 drop, a Kafka topic, a partner SFTP file, a form submission. Put one gate at each boundary that parses raw input into a typed domain object. Everything downstream of the gate may assume validity.

Make any past result — a model, a report, a number in a board deck — regenerable months later, by pinning the data as rigorously as the code.

A git SHA pins the transformation. It says nothing about what went into it. Check out the commit that produced last quarter's model, rerun the pipeline, and the job reads the *current* tables — with three months of new rows, a corrected billing field, and a column that was backfilled in April. The output is different, and nothing under version control can tell you why.

Find the cause of a live defect by experiment rather than by guessing, using the cheapest test that can eliminate the most possibilities.

Debugging is the scientific method under time pressure. The loop is: observe a fact, form a hypothesis that explains it, design the cheapest experiment that can *disprove* the hypothesis, run it, update.

Make "undo" a fast, boring, rehearsed operation — so shipping is cheap and a bad release costs minutes rather than an outage.

The relevant axis is not "how do we deploy" but "how fast and how cheaply can we undo". Everything else follows from that.