Java Development Agent

Router skill for general Java/JVM work. Treat Spring Boot as one supported framework, not the default for every project. Load only the matching rule files below.

Routing Protocol

Run these three steps in order before generating or modifying code.

Step 1 — Stack Detection

Inspect the project's build descriptor(s) first and record what they prove:

• pom.xml vs build.gradle(.kts) → Maven or Gradle; preserve whichever exists.
• Java version → maven.compiler.release / <java.version> / Gradle toolchain or sourceCompatibility.
• Spring Boot line → parent or BOM version: 2.x, 3.x, or 4.x (drives jakarta namespace, security DSL, Actuator/Micrometer config).
• Persistence → JPA/Hibernate vs MyBatis/MyBatis-Plus vs JDBC/jOOQ (dependencies plus repository/mapper layout).
• Lombok → present and annotation processing configured, or absent.
• Logging facade → SLF4J, Log4j2, or JUL in actual use.
• Test stack → JUnit 4 vs 5, Mockito, Testcontainers, Spring Boot test slices.

Existing evidence beats this skill's defaults. If a descriptor answers a question, do not assume otherwise.

Step 2 — Lazy Routing (Progressive Disclosure)

Classify the task, then read only the 1–3 highest-matching rule files from the route table. Never load every rule file for one task — it inflates the context window without improving the answer.

• Unknown/general Java task: load core/java-general-development.md only if classification or the default choice is unclear.
• API/exception/version work: load the specific core/... rule before framework rules.
• Build edits: load exactly one build-tools/... rule matching the detected build tool.
• Spring Boot edits: load the primary spring-boot/... rule only when the project actually uses Spring Boot.
• Broad code review: start with code-review/cr-anti-patterns.md, then add specific risk files.
• Test work: load testing/test-layering.md first, then the framework-specific test file.
• JVM incident: load the symptom file first; add GC/thread/resource files only when evidence points there.
• Do not load README files or examples/ unless the user asks for usage docs.

Step 3 — Convention Priority

The target project's existing code style, architecture, and module conventions outrank this skill's rules. When they conflict, follow the project and say so explicitly.

Defaults

• Respond in the user's language; keep code unchanged unless editing.
• Do not introduce Spring Boot, Maven, Gradle, Lombok, MyBatis-Plus, JPA, Testcontainers, or Java 17+ syntax unless the project already uses it or the user asks.
• If creating a new project and no preference is given: choose a dependency-supported Java LTS baseline (17 or newer), infer Maven or Gradle from the surrounding repository, use JUnit 5, constructor-based design, SLF4J-compatible logging, and immutable DTOs where practical.
• For a new Spring Boot project, verify the current stable release, Java/build requirements, and third-party starter compatibility from official sources before choosing a line. For existing projects, keep their supported line unless migration is requested.
• Do not choose a persistence framework by geography or popularity. Preserve the existing choice; for greenfield work, select JDBC, jOOQ, MyBatis/MyBatis-Plus, or JPA/Hibernate from the actual query model and team constraints.
• Prefer constructor injection in DI frameworks. Use Lombok (@RequiredArgsConstructor, @Slf4j) only when the project already uses Lombok; otherwise write explicit constructors/loggers.
• If multiple modules or frameworks exist, modify only the affected module unless the user asks for a cross-cutting change.
• Do not edit generated output unless explicitly requested; edit the source template, annotation processor input, schema, or generator configuration instead.

Work Rules

• Inspect only relevant files before editing: build descriptor, source layout, dependency versions, framework style, and tests around the change.
• Prefer the smallest safe change; do not perform broad refactors unless requested.
• If business behavior is unclear, ask one concise question instead of inventing rules.
• For non-trivial work, report: change reason, impact scope, verification performed, verification not performed, and the narrowest verification command/result.

Route By Task

Assets

• assets/pom-spring-boot-3.xml: opt-in Spring Boot 3.x + MyBatis-Plus Maven example.
• assets/pom-spring-boot-2.xml: opt-in legacy Spring Boot 2.7 maintenance example.
• assets/controller-service-test.java: opt-in Spring Boot 3 + MyBatis-Plus skeleton; split it into real files before use.
• assets/application.yml.template: opt-in multi-environment Spring Boot + MyBatis-Plus config example.