Claude Skills by snoodleboot-io

Apply Arrange-Act-Assert pattern for clear tests

Apply Arrange-Act-Assert pattern for clear, maintainable tests with detailed guidance

Systematic approach to achieving comprehensive test coverage

Comprehensive systematic approach to achieving complete test coverage through structured category-based testing

Produce test data that is deterministic, isolated per test, and states its intent in the test that uses it.

These three are not interchangeable, and picking the wrong one is the root of a surprising share of order-dependent failures.

Guidelines for when and how to use mocks in tests

Comprehensive guidelines for when and how to use mocks, stubs, and fakes in tests

Decide what to test at which level, so the suite catches real defects without becoming slow or brittle.

Three shapes get argued about as if one were correct. Each is a claim about where your defects live, and that is an empirical question about your architecture — not a matter of taste.

Enumerate what could go wrong in a system before deciding what to do about it — inventory the assets worth attacking, the entry points that reach them, and the actors who would try.

Threat identification fails when it starts from an architecture diagram, because diagrams show components and attackers pursue assets. Build the asset register first and rate each on confidentiality, integrity, and availability separately.

A structured pass over a design — diagram, trust boundaries, STRIDE, mitigations — that finds whole classes of flaws while they are still cheap to fix.

Every methodology — STRIDE, PASTA, LINDDUN, attack trees — is a technique for answering four questions in order:

Prepare temporal data for modeling without letting information from the future reach a model that will only ever see the past.

Almost every downstream bug traces back to an index that was assumed regular and was not. Make the grid explicit before anything else.

Use the type system to make illegal states unrepresentable, while keeping types simple enough that the next reader can follow them.

`any` opts a value out of type checking entirely, and that opt-out is contagious — every expression derived from it is also unchecked. `unknown` is the safe top type: it holds any value but permits no operation until you narrow it.

Find out what people actually struggle with by asking about their past, not their future — because everyone says yes to a hypothetical and almost nobody buys it.

The name comes from a simple test — could you ask this question of your own mother and get a useful answer, given she loves you and wants you to succeed? "Do you think my app is a good idea?" fails. "How did you handle that last time?" passes, because the answer is a fact about her life, not a judgement of your idea.

Pick the testing method that can actually answer your question, and size it correctly — most bad research is a good method aimed at the wrong question.

Start from the question, in writing, before choosing anything. Most wasted research is a well-run study that structurally could not answer what was asked.

Write interface copy that tells the user what happened and what to do next, in the fewest words that still leave no decision unexplained.

An error message has exactly one job: get the user unstuck. It needs three components, and most shipped errors have none of them.

Find actual weaknesses in a built or running system, then triage them by real-world risk so the small number that matter get fixed first.

Threat modeling asks what could go wrong in a design. Vulnerability assessment asks what *is* wrong in the thing you actually built and deployed. The first is predictive and cheap; the second is empirical and finds the gap between the design you modeled and the system you shipped — the misconfigured bucket, the forgotten staging host, the library that went stale.