dmitriy-iliyov
UserSkills for Claude Code that carry a house style for Java projects
Categories
Indexed Skills (11)
javadoc-refactor
The procedure for bringing a project's javadoc back in line with code that has moved - the file inventory, two passes in a fixed order (distortions and absences first, restatements second), how to find each kind of stale comment cheaply, how to verify the result, and how to report it. Use it after a refactor has left comments describing types that no longer exist, when asked to go over the javadoc of a module or of a set of changed files, or when judging whether existing comments still describe what the code does.
javadoc-style
The javadoc style for a Java project - what earns a comment and what never does, where a type, method or constructor gets one and where nothing goes at all, and the formatting rules. Load it before writing or rewriting javadoc, and whenever judging whether an existing comment is worth its place. The procedure for auditing existing javadoc against the code it describes is the separate `javadoc-refactor` skill.
test-refactor
The procedure for bringing a multi-module Maven/Java project's tests back to green and up to coverage after a refactor - module by module, package by package, contract first. Use it when a refactor has left tests failing or not compiling, when a module's coverage has to be raised deliberately rather than opportunistically, or when asked to "go through the modules and sort out the tests".
test-style
The testing style for a Java project - how tests are named, what each of the three levels (UT/IT/CT) is responsible for, what may be mocked and what may not, and what has to be asserted at each level. Load it before writing or rewriting a test, and whenever judging whether an existing test still follows the house style. The procedure for bringing a module's tests back to green after a refactor is the separate `test-refactor` skill.
controller-advice-style
The house style for error responses of a Spring MVC REST application - `@RestControllerAdvice`, `@ExceptionHandler`, `ProblemDetail` (RFC 9457), `ResponseEntityExceptionHandler`, `AuthenticationEntryPoint`, `AccessDeniedHandler`. Load it before writing or changing any of them, when a new exception has to reach the client, when shaping validation `errors`, and when an endpoint returns 403 where 401 was expected, a `@PreAuthorize` denial comes back as 500, a status is lost to a catch-all handler, one module's exception is answered by another module's advice, or an error body has its fields nested under `properties`. Not for the controllers themselves (the separate `controller-style` skill) and not for documenting errors in Swagger (the separate `swagger-style` skill).
controller-style
The house style for Spring MVC REST controllers - `@RestController`, `@RequestMapping`, `@GetMapping` / `@PostMapping`. Load it before writing or rewriting a controller or an endpoint, when choosing a URL, an HTTP verb or a response status for one, when binding path variables, query parameters, a `@RequestBody`, a `@ModelAttribute` filter or a multipart `@RequestPart`, when adding a request record or its `@Valid` constraints, when injecting services into a controller, placing `@PreAuthorize` or getting the current user through `@AuthenticationPrincipal`, when deciding between returning a body and `ResponseEntity`, and when judging whether a controller is thin enough. Not for exception handling and error responses (the separate `controller-advice-style` skill), not for Swagger annotations (the separate `swagger-style` skill), not for the service layer, and not for server-side rendering with views.
swagger-style
The house style for springdoc-openapi annotations on a Spring REST controller and its DTOs - `@Operation`, `@ApiResponses`, `@Parameter`, `@Schema`, `@ParameterObject`. Load it before adding or changing `io.swagger.v3.oas.annotations` on a controller, a record or an enum, when a new endpoint is added to an annotated controller, when checking `/v3/api-docs` or Swagger UI against the code, and when Swagger UI documents an error as returning the success body, shows a `@ModelAttribute` filter as one object parameter, asks for a parameter the server fills in itself, answers 415 on a multipart "Try it out", or drops enum descriptions. Not for javadoc (the separate `javadoc-style` skill), and not for designing paths, statuses or error responses - those are the `controller-style` and `controller-advice-style` skills, taken as given here.
javadoc-refactor
The procedure for bringing a project's javadoc back in line with code that has moved - the file inventory, two passes in a fixed order (distortions and absences first, restatements second), how to find each kind of stale comment cheaply, how to verify the result, and how to report it. Use it after a refactor has left comments describing types that no longer exist, when asked to go over the javadoc of a module or of a set of changed files, or when judging whether existing comments still describe what the code does.
javadoc-style
The javadoc style for a Java project - what earns a comment and what never does, where a type, method or constructor gets one and where nothing goes at all, and the formatting rules. Load it before writing or rewriting javadoc, and whenever judging whether an existing comment is worth its place. The procedure for auditing existing javadoc against the code it describes is the separate `javadoc-refactor` skill.
test-refactor
The procedure for bringing a multi-module Maven/Java project's tests back to green and up to coverage after a refactor - module by module, package by package, contract first. Use it when a refactor has left tests failing or not compiling, when a module's coverage has to be raised deliberately rather than opportunistically, or when asked to "go through the modules and sort out the tests".
test-style
The testing style for a Java project - how tests are named, what each of the three levels (UT/IT/CT) is responsible for, what may be mocked and what may not, and what has to be asserted at each level. Load it before writing or rewriting a test, and whenever judging whether an existing test still follows the house style. The procedure for bringing a module's tests back to green after a refactor is the separate `test-refactor` skill.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.