Claude Skills by CasLubbers

Selects, applies, and pushes back on the 23 Gang of Four design patterns. Covers intent, fit, trade-offs, and the cheaper alternative that usually wins. Use when choosing between patterns, naming an existing structure, or refactoring toward one — and when the user says "which pattern", "what pattern should I use", "design pattern", "GoF", "factory", "strategy", "observer", "decorator", "adapter", "singleton", "visitor", or describes a shape a pattern solves: swappable algorithms, notifying su...

Enforces Go package and API design — small exported surfaces, packages named for what they provide, functional options instead of growing constructors, context first, no init side effects, and changes that stay backward compatible. Use when creating or restructuring Go packages, designing an exported API or library, or reviewing a public interface, and when the user mentions package layout, internal/, functional options, breaking changes, semantic import versioning, or asks "how should I stru...

Enforces safe Go concurrency — every goroutine has a known stop condition, context propagates cancellation, channel ownership and direction are explicit, and shared state is protected or not shared. Use when writing or reviewing Go that starts goroutines, uses channels, sync primitives, or context, and when the user mentions goroutine leaks, deadlock, data race, WaitGroup, errgroup, select, mutex, worker pool, "-race", or asks "is this concurrent code safe", "why does this hang".

Enforces Go error handling — errors as values, wrapping with %w, errors.Is and errors.As over type assertions, sentinel and custom error types, and when panic is acceptable. Use when writing, reviewing, or debugging Go error paths, and when the user mentions err != nil, error wrapping, errors.Is, errors.As, sentinel errors, panic, recover, errors.Join, or asks "how should I return this error", "why is errors.Is failing", "should this panic".

Enforces idiomatic Go style — name length scaled to scope, no stutter, useful zero values, guard clauses, correct defer placement, composition over inheritance, and doc comments in the required form. Use when writing, reviewing, or refactoring any Go code, and when the user asks whether something is idiomatic, mentions gofmt, go vet, golangci-lint, package naming, receiver names, struct embedding, or asks "is this Go-ish", "does this read like Go", "clean up this Go".

Enforces Go interface design — interfaces defined by the consumer, kept to one or two methods, accepted as parameters while structs are returned, and never created before a second implementation exists. Use when writing or reviewing Go abstractions, mocks, or package boundaries, and when the user mentions interface design, mocking, dependency injection, "accept interfaces return structs", io.Reader, io.Writer, generics vs interfaces, or asks "should this be an interface", "how do I test this ...

Enforces idiomatic Go testing — table-driven cases with subtests, the standard library over assertion frameworks, t.Cleanup for teardown, httptest for HTTP, golden files, fuzzing, and benchmarks that measure. Use when writing or reviewing Go tests, and when the user mentions table tests, t.Run, t.Parallel, testify, testdata, golden files, httptest, go test -race, coverage, benchmarks, fuzz, or asks "how do I test this in Go".

Applies the Boy Scout Rule to Java — leave every file a little cleaner than you found it, with small safe improvements made alongside the change you were asked for. Use when fixing, editing, debugging, or extending existing Java code, and when the user says "while you're at it", "any quick wins", "tidy this up", "improve this a bit", or you are already editing a file that has obvious small problems nearby.

Complete Clean Code reference for Java 21+ in one skill — naming, methods, comments, general quality, and tests, with modern idioms (records, sealed types, pattern matching, Optional, streams). Use when writing, reviewing, or refactoring any Java code and you want the whole catalog at once rather than one focused area.

Enforces comment and Javadoc hygiene in Java — no commented-out code, no author or ticket metadata, no comments restating the code, and Javadoc that documents contracts rather than repeating signatures. Use when writing or reviewing Java comments and Javadoc, and when the code shows commented-out blocks, TODO or FIXME banners, @author or date tags, boilerplate Javadoc, or documentation that no longer matches the method.

Enforces method design in Java 21+ — small methods that do one thing, at most three parameters, no boolean flag arguments, no null returns or arguments, and command-query separation. Use when writing or refactoring Java methods and constructors, and when the code shows long methods, parameter lists of four or more, boolean flags, deep nesting, output parameters, or methods returning null. Also trigger on: private helpers placed above the public methods that call them, a class that must be rea...

Enforces general code quality in Java 21+ — DRY, no magic numbers, immutability by default, sealed hierarchies and pattern matching over instanceof chains, encapsulation over getters and setters, and streams used where they clarify. Use when reviewing or refactoring Java for quality, and when the code shows duplication, hardcoded values, long if-else or switch chains on type, mutable shared state, anaemic classes, deep call chains like a.getB().getC().getD(), or clever one-liners. Also trigge...

Enforces naming in Java 21+ — descriptive names, names matched to scope, no Hungarian notation or I-prefixed interfaces, no meaningless suffixes like Manager or Helper, and names that reveal side effects. Use when naming or renaming variables, fields, methods, classes, records, interfaces, or packages in Java, and when the user asks "rename this", "better name", "what should I call this", or the code shows cryptic identifiers, `Impl` suffixes, or getters that mutate.

Enforces test quality in Java with JUnit 5 and AssertJ — one concept per test, boundary coverage, fast isolated tests, parameterised cases, and no disabled tests without a reason. Use when writing or reviewing Java tests, and when the user mentions JUnit, AssertJ, Mockito, Testcontainers, @ParameterizedTest, @Disabled, flaky tests, coverage gaps, or asks "how should I test this".

Use when fixing, editing, changing, debugging, or working with any Python code. Applies the Boy Scout Rule—always leave code cleaner than you found it. Orchestrates other clean code skills as needed. Also trigger on: "while you're at it", "any quick wins", "improve this a bit", "anything else obviously wrong", or when editing existing Python and an adjacent small cleanup is possible alongside the asked-for change.

Use when writing, fixing, editing, or reviewing Python comments and docstrings. Enforces Clean Code principles—no metadata, no redundancy, no commented-out code. Also trigger on: commented-out code blocks, TODO/FIXME banners, author/ticket/date metadata in comments, docstrings that no longer match the code, redundant comments that restate the code (e.g. `i += 1 # increment i`), or asks like "is this comment useful", "why is this block commented".

Use when writing, fixing, editing, or refactoring Python functions. Enforces Clean Code principles—maximum 3 arguments, single responsibility, no flag parameters. Also trigger on: functions with 4+ parameters, boolean flag parameters like `enabled=True`, functions that mutate their arguments in place, one-off `util`/`helper` functions that are never called, or asks like "too many arguments", "split this function", "is this still used". Also trigger on: helper functions defined above the entry...

Use when writing, fixing, editing, or reviewing Python code quality. Enforces Clean Code's core principles—DRY, single responsibility, clear intent, no magic numbers, proper abstractions. Also trigger on: duplicated logic across files or branches (G5), magic numbers or hardcoded values (G25), long if/elif chains that should be polymorphism (G23), chained property access like `a.b.c.d` (G36), functions juggling multiple responsibilities (G30), clever one-liners whose intent is not obvious (G16...

Use when naming, renaming, or fixing names of variables, functions, classes, or modules in Python. Enforces Clean Code principles—descriptive names, appropriate length, no encodings. Also trigger on: single-letter or cryptic identifiers (`d`, `x`, `proc`), Hungarian notation (`str_name`, `lst_users`, `i_count`), `I`-prefixed classes, function names that hide side effects (e.g. `get_config` that also writes a file), non-standard abbreviations, or asks like "rename this", "what does this variab...

Use when writing, fixing, editing, or refactoring Python tests. Enforces Clean Code principles—fast tests, boundary coverage, one assert per test. Also trigger on: slow or flaky tests, `@pytest.mark.skip` without a clear reason, tests that only cover the happy path, tests with multiple assertions about different concepts, missing boundary cases (empty input, off-by-one, page zero), or asks about "coverage gap", "edge case", "did we test".

Use when writing, fixing, editing, reviewing, or refactoring any Python code. Enforces Robert Martin's complete Clean Code catalog—naming, functions, comments, DRY, and boundary conditions.

Use when fixing, editing, changing, debugging, or working with any TypeScript code. Applies the Boy Scout Rule—always leave code cleaner than you found it. Orchestrates other clean code skills as needed. Also trigger on: "while you're at it", "any quick wins", "improve this a bit", "anything else obviously wrong", or when editing existing TypeScript and an adjacent small cleanup is possible alongside the asked-for change.

Use when writing, fixing, editing, or reviewing TypeScript comments and TSDoc. Enforces Clean Code principles—no metadata, no redundancy, no commented-out code. Also trigger on: commented-out code blocks, TODO/FIXME banners, author/ticket/date metadata in comments or TSDoc, TSDoc that no longer matches the code, redundant comments that restate the code (e.g. `i += 1; // increment i`), or asks like "is this comment useful", "why is this block commented".

Use when writing, fixing, editing, or refactoring TypeScript functions. Enforces Clean Code principles—maximum 3 arguments, single responsibility, no flag parameters. Also trigger on: functions (or React components) with 4+ parameters/props, boolean flag parameters like `isTest`, functions that mutate their parameters (e.g. push to an input array), unused exports or dead helper functions, or asks like "too many props", "split this function", "is this still used". Also trigger on: helpers defi...

Use when writing, fixing, editing, or reviewing TypeScript code quality. Enforces Clean Code's core principles—DRY, single responsibility, clear intent, no magic numbers, proper abstractions. Also trigger on: duplicated logic across files or branches (G5), magic numbers or hardcoded strings (G25), long if/else chains that should be union types plus polymorphism (G23), chained property access like `a.b.c.d` or long optional-chain trains (G36), functions juggling multiple responsibilities (G30)...

Use when naming, renaming, or fixing names of variables, functions, classes, interfaces, or modules in TypeScript. Enforces Clean Code principles—descriptive names, appropriate length, no encodings. Also trigger on: single-letter or cryptic identifiers (`d`, `x`, `proc`), Hungarian notation (`strName`, `arrUsers`, `nCount`), `I`-prefixed interfaces (`IUserRepository`), function names that hide side effects (e.g. `getConfig` that also mutates state), ambiguous names like `rename(source, target...

Use when writing, fixing, editing, or refactoring TypeScript tests. Enforces Clean Code principles—fast tests, boundary coverage, one assert per test. Also trigger on: slow or flaky tests, `test.skip`/`it.skip`/`.todo` without a clear reason, `test.only` left in committed code, tests that only cover the happy path, tests with multiple assertions about different concepts, missing boundary cases (empty arrays, off-by-one, page zero), or asks about "coverage gap" / "edge case".

Use when writing, fixing, editing, reviewing, or refactoring any TypeScript code. Enforces Robert Martin's complete Clean Code catalog—naming, functions, comments, DRY, and boundary conditions.