CasLubbers
UserClaude Code skills for Clean Code (Python, TypeScript, Java), idiomatic Go, and Gang of Four design patterns.
Categories
Indexed Skills (13)
go-api-design
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 structure this package", "is this a good API".
go-concurrency
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".
go-errors
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".
go-idiom
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".
go-interfaces
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 dependency".
go-tests
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".
java-boy-scout
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.
java-clean-code
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.
java-clean-comments
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.
java-clean-names
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.
java-clean-tests
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".
python-clean-code
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.
typescript-clean-code
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.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.