Claude Skills for Java: Review and Test Templates

Claude skills for Java are saved prompt instructions that apply a consistent review checklist and test planning structure to your code. Call a skill by name in a Claude Project and get the same output every time, instead of retyping the Java-specific criteria that matter to your team.

Tools like fenbs store the project conventions and lessons from past bugs alongside the skills. A connected assistant that reads those at the start of a session applies the team's actual standards, not generic Java advice.

What Java-specific review criteria to include

A useful Java review skill goes beyond general code quality. It checks for the issues that appear most often in Java codebases: unchecked exceptions that swallow useful context, null handling inconsistencies across method boundaries, resource management gaps that cause leaks, and naming deviations from the project conventions.

Exception handling is one of the most common problem areas. An empty catch block that swallows an exception silently is worse than no catch block at all: the caller has no way to know something went wrong. A catch block that catches Exception rather than a specific type can hide bugs that the caller should see. A custom exception that carries no context beyond its class name leaves the person debugging with no useful information.

Null handling in Java requires active discipline because the type system does not enforce it. A method that returns null for an error condition instead of throwing or returning an Optional forces every caller to add a null check or risk a NullPointerException. Inconsistent null behavior across a codebase compounds over time. The review skill catches boundary crossings where null can propagate.

A skill for reviewing Java code changes

This skill checks a code change against Java-specific criteria. The checklist covers exceptions, null safety, resource management, and naming. Adjust the items to match your project's actual conventions before saving.

Review the following Java code change.

Change description: {{what the change is meant to do}}
Code:
{{paste the diff or the relevant classes}}

Check each item and mark Pass, Fail, or Not applicable:

Exceptions and error handling:
- [ ] Checked exceptions are handled or declared with a reason
- [ ] Catch blocks do not swallow exceptions silently
- [ ] Custom exceptions carry enough context for debugging

Null safety:
- [ ] Nulls are handled at method boundaries
- [ ] Optional is used where a null return is a normal case
- [ ] No NullPointerException risk in the critical path

Resource management:
- [ ] Streams, connections, and IO are closed in finally or try-with-resources
- [ ] No resource leak in the error path

Naming and structure:
- [ ] Class, method, and variable names follow project conventions
- [ ] Methods do one thing and are named for what they do
- [ ] No magic numbers or unexplained string literals

For each Fail, write one sentence explaining the problem and one sentence on how to fix it.
End with: Safe to merge: Yes | No | With changes, and one-line reason.

The try-with-resources check is worth elaborating. Java automatically closes resources that implement AutoCloseable when the try block exits, including in error paths. A finally block that closes a resource only handles the normal exit path unless it is written carefully. try-with-resources is more reliable and cleaner to read.

The "methods do one thing" check is subjective and the skill output will reflect that. If the reviewer finds it unhelpful for a specific codebase, remove it from the skill or replace it with a more specific convention check. A skill that produces useful output consistently is better than one that covers everything but produces noise.

A skill for planning meaningful Java tests

A test planning skill helps you think through what to test before writing tests. Starting from a plan catches the cases that are easy to miss: the null input for each parameter, the exception path, the boundary value that is one off from the standard case. Discovering gaps after writing the tests means rewriting setup code and reorganizing the test class.

Write a test plan for the following Java change.

Change description: {{what the change does}}
Class under test: {{class name and brief responsibility}}
External dependencies: {{databases, APIs, message queues, or other services it touches}}

Output:

Unit tests (no external dependencies):
  - Test: [what to test] | Arrange: [setup] | Assert: [expected outcome]
  (list each)

Integration tests (with real or stubbed dependencies):
  - Test: [what to test] | Dependencies: [which ones] | Assert: [expected outcome]
  (list each)

Edge cases:
  - [null inputs, boundary values, concurrent access, large inputs]

Tests to add to regression:
  - [existing test names or areas to re-run]

If the change is too large to test meaningfully in isolation, note why and suggest a smaller scope.

The "too large to test meaningfully" prompt at the end of the skill is intentional. A change that cannot be tested in isolation is often a sign that the change is too large, or that the code under test needs to be refactored before testing. This is useful information to surface before writing tests rather than after.

How lessons make the skills better over time

After a bug reaches production, record what the review skill missed and why. If a resource leak in an error path escaped review because the code path only appeared under a specific database state, add the lesson: "Review skills for database access methods must include an error path check for every resource opened." The next review catches it.

Test planning lessons are equally valuable. If a boundary case that the test plan did not surface caused a production bug, record the pattern. A team that consistently records and applies lessons ends up with review and test planning skills tuned to the actual failure modes of its codebase. Generic Java skills are a starting point; the lessons turn them into something that reflects what actually breaks in your specific system. The difference between a generic checklist and a project-tuned one becomes clear the first time a review catches a bug that the generic version would have missed.

How to do this with fenbs

1. Create a free account and add a project for the Java codebase or team.
2. Add each skill to Skills and prompts: "Java code review", "Java test plan".
3. Add the project conventions as Decisions and rules: naming scheme, exception policy, null handling approach.
4. Connect Claude over MCP from Integrations. At the start of a session, ask Claude to read the conventions before running a review skill.
5. After each bug or production issue, add a lesson: what the review missed and what to check next time.

For broader skill patterns, see Claude skills examples and how to create a Claude skill. For an overview of how skills, Projects, and Artifacts fit together, see Claude Projects vs Skills vs Artifacts. Starting with one skill and one project is the fastest way to see the value before building out the full set.