
Java Coding Standards
Apply Spring Boot or Quarkus-aware Java 17+ conventions when writing or reviewing service code, packages, CDI, and reactive patterns.
Overview
Java Coding Standards is an agent skill most often used in Build (also Ship review) that enforces Java 17+ naming, immutability, Optional, streams, exceptions, and Spring Boot or Quarkus-specific layout from detected bui
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill java-coding-standardsWhat is this skill?
- Auto-detects Quarkus vs Spring Boot from build files and applies framework-tagged rules
- Java 17+ guidance for records, sealed classes, pattern matching, Optional, streams, and generics
- Shared principles: immutable-by-default, fail-fast exceptions, consistent packages
- Quarkus-specific CDI scopes, Panache entities, and reactive pipeline conventions
- Structured workflow for both writing new code and reviewing existing JVM services
Adoption & trust: 6k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Spring Boot and Quarkus codebases drift on naming, mutability, Optional misuse, and framework-specific patterns because every agent session reinvents style from scratch.
Who is it for?
Solo builders maintaining or generating Java 17+ APIs on Spring Boot or Quarkus who want agent output to match team conventions automatically.
Skip if: Pure Kotlin projects, Android-only Java without Spring/Quarkus, or teams that already enforce the same rules exclusively via SpotBugs/Checkstyle with no agent authoring.
When should I use this skill?
Writing or reviewing Java in Spring Boot or Quarkus projects; enforcing naming, immutability, exceptions, records, Optional, streams, generics, packages, or Quarkus CDI/Panache/reactive work.
What do I get? / Deliverables
New and reviewed Java service code follows a single detected-framework rule set with clear [SPRING], [QUARKUS], or shared-only branches.
- Convention-aligned Java source or review comments
- Framework branch ([SPRING], [QUARKUS], or shared) applied to touched files
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Backend JVM services are authored primarily during Build; standards anchor the canonical shelf there even when invoked during review. Covers service-layer naming, immutability, exceptions, and Quarkus/Spring layout—core backend implementation work.
Where it fits
Scaffold a new REST service package structure with immutable DTOs and framework-detected naming rules.
Review a PR for Optional anti-patterns and wrong CDI scope usage on a Quarkus repo.
Align reactive pipeline code with Quarkus conventions after adding a messaging integration.
How it compares
Use as procedural review and authoring guidance rather than replacing SpotBugs, Error Prone, or ArchUnit enforcement.
Common Questions / FAQ
Who is java-coding-standards for?
Indie and small-team developers building Spring Boot or Quarkus backends who want Claude, Cursor, or Codex to write and review Java with consistent JVM conventions.
When should I use java-coding-standards?
During Build when implementing services, packages, records, or reactive pipelines; during Ship when reviewing JVM pull requests; whenever you need Optional, streams, or CDI/Panache patterns checked against framework-specific tags.
Is java-coding-standards safe to install?
It is documentation-style procedural knowledge with no mandated shell or network access; review the Security Audits panel on this Prism page before installing from any third-party skill source.
SKILL.md
READMESKILL.md - Java Coding Standards
# Java Coding Standards Standards for readable, maintainable Java (17+) code in Spring Boot and Quarkus services. ## When to Use - Writing or reviewing Java code in Spring Boot or Quarkus projects - Enforcing naming, immutability, or exception handling conventions - Working with records, sealed classes, or pattern matching (Java 17+) - Reviewing use of Optional, streams, or generics - Structuring packages and project layout - **[QUARKUS]**: Working with CDI scopes, Panache entities, or reactive pipelines ## How It Works ### Framework Detection Before applying standards, determine the framework from the build file: - Build file contains `quarkus` → apply **[QUARKUS]** conventions - Build file contains `spring-boot` → apply **[SPRING]** conventions - Neither detected → apply shared conventions only ## Core Principles - Prefer clarity over cleverness - Immutable by default; minimize shared mutable state - Fail fast with meaningful exceptions - Consistent naming and package structure - **[QUARKUS]**: Favor build-time over runtime processing; avoid runtime reflection where possible ## Examples The sections below show concrete Spring Boot, Quarkus, and shared Java examples for naming, immutability, dependency injection, reactive code, exceptions, project layout, logging, configuration, and tests. ## Naming ```java // PASS: Classes/Records: PascalCase public class MarketService {} public record Money(BigDecimal amount, Currency currency) {} // PASS: Methods/fields: camelCase private final MarketRepository marketRepository; public Market findBySlug(String slug) {} // PASS: Constants: UPPER_SNAKE_CASE private static final int MAX_PAGE_SIZE = 100; // PASS: [QUARKUS] JAX-RS resources named as *Resource, not *Controller public class MarketResource {} // PASS: [SPRING] REST controllers named as *Controller public class MarketController {} ``` ## Immutability ```java // PASS: Favor records and final fields public record MarketDto(Long id, String name, MarketStatus status) {} public class Market { private final Long id; private final String name; // getters only, no setters } // PASS: [QUARKUS] Panache active-record entities use public fields (Quarkus convention) @Entity public class Market extends PanacheEntity { public String name; public MarketStatus status; // Panache generates accessors at build time; public fields are idiomatic here } // PASS: [QUARKUS] Panache MongoDB entities @MongoEntity(collection = "markets") public class Market extends PanacheMongoEntity { public String name; public MarketStatus status; } ``` ## Optional Usage ```java // PASS: Return Optional from find* methods // [SPRING] Optional<Market> market = marketRepository.findBySlug(slug); // [QUARKUS] Panache Optional<Market> market = Market.find("slug", slug).firstResultOptional(); // PASS: Map/flatMap instead of get() return market .map(MarketResponse::from) .orElseThrow(() -> new EntityNotFoundException("Market not found")); ``` ## Streams Best Practices ```java // PASS: Use streams for transformations, keep pipelines short List<String> names = markets.stream() .map(Market::name) .filter(Objects::nonNull) .toList(); // FAIL: Avoid complex nested streams; prefer loops for clarity ``` ## Dependency Injection ```java // PASS: [SPRING] Constructor injection (preferred over @Autowired on fields) @Service public class MarketService { private final MarketRepository marketRepository; public MarketService(MarketRepository marketRepository) { this.marketRepository = marketRepository; } } // PASS: [QUARKUS] Constructor injection @ApplicationScoped public class MarketService { private final MarketRepository marke