agentleFS
alexderzalexderz/agentic-toolbox/skills/lang-java/SKILL.md

lang-java

Skill5 starsChanged 46 days agoMITView on GitHub

use this when writing, reviewing, or testing Java — *.java, pom.xml, build.gradle. language only; not a Spring skill. do not use for Kotlin (load lang-kotlin).

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 5 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not add a second build tool.

    line 24
  2. Very specific:

    Never return null for a collection.

    line 33
  3. Very specific:

    Prefer final locals when the file already does.

    line 35
  4. Very specific:

    Prefer java.util.concurrent over home-rolled wait/notify.

    line 48
  5. Distinctive:

    No unsynchronized shared mutable state.

    line 51
  6. Distinctive:

    Test doubles at I/O boundaries.

    line 58
  7. Distinctive:

    No leaked persistence entities across a module boundary.

    line 64
  8. Distinctive:

    No string-built SQL or process commands.

    line 69

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Java

Language guide. No Spring / Jakarta religion. No scripts/. Process skills that may load with this one: load-with list.

Iron law

Nulls are explicit. Resources close themselves. Dependencies point inward.

Tooling / verify

# one of these, as the repo does
mvn -q test
gradle test

Do not add a second build tool. Read the surefire/gradle test output.

Idioms a linter misses

  • Records / sealed types when the language level allows and the type is data.
  • Try-with-resources for every AutoCloseable.
  • Constructor injection. Do not new a service inside another service if the module already injects.
  • Never return null for a collection; return empty.
  • equals and hashCode together. Prefer records.
  • Prefer final locals when the file already does. No clever var shadowing.
  • java.time over Date / Calendar for new code.

Errors

  • Specific exceptions. Wrap with cause. Do not catch Exception to return null.
  • Checked exceptions: do not punch them through a listener that cannot declare them — map at the boundary.

Concurrency

  • Prefer java.util.concurrent over home-rolled wait/notify.
  • Virtual threads: only if the project already uses them or the language level is there and you Ask first before flipping a thread model.
  • No unsynchronized shared mutable state.
  • synchronized on this is usually the wrong lock object for public types.

Testing

  • JUnit as the repo uses it. Assert on behavior, not log strings.
  • Test doubles at I/O boundaries. Do not mock the type under test.

PR review

  • New public API: null contract documented or non-null by type (Optional only when absence is the point).
  • No leaked persistence entities across a module boundary.
  • Module / package cycles.

Security

  • No string-built SQL or process commands.
  • Runtime.exec / ProcessBuilder: argument list, not a shell string.
  • No ObjectInputStream / Java serialization of untrusted bytes.
  • Paths stay inside an allowlisted root.

Always

  • Try-with-resources.
  • Empty collections, not null lists.
  • Tests for the new branch.

Ask first

  • Bumping the language level.
  • Adding Spring / Jakarta annotations in a non-Spring module.
  • Switching thread model to virtual threads.

Never

  • Empty catch (Exception e) {}.
  • Public mutable static state.
  • Raw types.
  • Runtime.exec with concatenated input.

Red flags

  • "I'll null-check it at every call"
  • "Spring will wire it" on a type that is not a bean
  • "it's just a static Map"

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.