Java Code Quality

This documentation was generated with the assistance of AI. Please report any inaccuracies.

Run this project’s Java static-analysis tools — Checkstyle, PMD, and SpotBugs — directly (via Maven goals or the Gradle checkstyleMain/pmdMain/spotbugsMain tasks), then read the generated XML reports to summarize every issue found, grouped by tool. This is a read-only reporting skill: it runs static analysis and reports results, it does not fix issues unless asked to as an explicit follow-up.

Purpose

iru-java-code-quality gives a fast, focused lint pass without paying for a full mvn site or ./gradlew check build (which also regenerates javadoc/site output or runs tests). It runs the three analysis tools directly, parses their XML reports itself rather than relying on console output — which only shows progress, not the full issue list — and can scope its summary to a single file/class even though the underlying run always analyzes the whole project.

It first detects the build tool exactly as iru-java-test does (pom.xml means Maven; build.gradle(.kts) / settings.gradle(.kts) means Gradle with the wrapper preferred; an Android Gradle plugin means iru-android-code-quality is the right skill instead). It also decides what these tools can see: Checkstyle and PMD parse Java source only, and SpotBugs sees Kotlin only as noisy bytecode, so Kotlin sources are not covered here. A pure Kotlin project is pointed at iru-kotlin-code-quality (detekt + ktlint) and the run stops; a mixed Java/Kotlin project analyzes the Java sources and states in its report that the Kotlin sources still need iru-kotlin-code-quality.

On Maven it runs mvn clean compile checkstyle:checkstyle pmd:pmd spotbugs:spotbugs (clean compile is required because SpotBugs analyzes compiled bytecode). On Gradle it first lists which of the three tasks the build actually defines (a task that exists nowhere fails the whole invocation) and runs exactly those with clean …​ --continue — --continue is required because each tool fails its own task when it finds issues and Gradle would otherwise never run the remaining tools; a task that failed because it found violations still wrote its report. If none of the tasks exists, the skill reports that none of these tools is configured and stops without editing the build.

When the Kotlin Multiplatform plugin is applied anywhere in the build, the skill stops and points to KMP Code Quality instead.

Purpose group

Java Development Tooling

Plugin

Shipped by the iru-java plugin of the ai-catalog marketplace (install with /plugin install iru-java@ai-catalog; see Plugins).

Invocation

/iru-java-code-quality
/iru-java-code-quality <path-or-class-name>

Inputs

Argument Required Description Default

path-or-class-name

No

Scopes the reported summary to matches in a specific file/class: Checkstyle/PMD entries whose <file name> ends in /<Name>.java, and SpotBugs entries whose <Class classname> equals <Name>, ends in .<Name>, or is nested under it (e.g. Foo$Inner for Foo). The underlying run still analyzes the whole project regardless — none of the three tools expose a per-file selector like Surefire’s -Dtest.

None — omitting it summarizes every issue across the whole project.

Report locations: Maven writes target/checkstyle-result.xml, target/pmd.xml and target/spotbugsXml.xml; Gradle writes build/reports/checkstyle/main.xml, build/reports/pmd/main.xml and, only when the build enables an XML report, build/reports/spotbugs/main.xml. If SpotBugs has no XML report configured the skill reads its HTML/SARIF output or, when no file is written at all, parses its console lines (run with --console=plain); it never edits the build to switch a report format on. Gradle’s pmd plugin defaults to the errorprone ruleset only, so an empty PMD report there does not mean stricter Maven-style rulesets were applied.

Outputs

  • A plain-text summary in the conversation — never a written file.

  • Findings grouped by tool (Checkstyle, PMD, SpotBugs), then by file.

  • Per issue: file:line, the rule/check name, and the message.

  • A total issue count per tool at the top and an overall total; a tool with zero issues in the requested scope is called out as clean, and on Gradle a tool whose task is not defined is reported as "not configured" rather than "zero issues".

  • For projects with Kotlin sources, a closing one-line note that they were not covered and need iru-kotlin-code-quality.

  • No source, Checkstyle, PMD, or SpotBugs configuration is ever modified.

Execution flow

flowchart TD A["Start /iru-java-code-quality\n(optional path-or-class-name)"] --> B{"Step 0: Build tool and languages?"} A -. "KMP plugin applied" .-> KMP["Stop: hand off to iru-kmp-code-quality"] B -- "Android Gradle plugin" --> B1["Stop: use iru-android-code-quality"] B -- "pure Kotlin project" --> B2["Stop: use iru-kotlin-code-quality"] B -- "Maven" --> C["Step 1: mvn clean compile checkstyle:checkstyle\npmd:pmd spotbugs:spotbugs"] B -- "Gradle, or mixed Java/Kotlin" --> D["Step 1: list which of checkstyleMain,\npmdMain, spotbugsMain exist"] D --> D1{"Any defined?"} D1 -- no --> D2["Report: none configured, stop"] D1 -- yes --> D3["Run clean plus the defined tasks\nwith --continue"] C --> E{"Build or compile failed?"} D3 --> E E -- yes --> F["Report failure, stop\n(reports not freshly regenerated)"] E -- no --> G["Step 2: read Checkstyle, PMD and SpotBugs reports"] G --> H{"Scope argument given?"} H -- yes --> I["Extract only the matching\nfile/class entries"] H -- no --> J["Keep full project-wide results"] I --> K["Step 3: group by tool, then file"] J --> K K --> L["Report file:line, rule, message, totals;\nnote uncovered Kotlin sources"]

Dependencies

Invokes

None — iru-java-code-quality is a leaf skill; it only runs Maven/Gradle commands and reads the generated Checkstyle/PMD/SpotBugs reports. It names iru-kotlin-code-quality and iru-android-code-quality as the right skills for Kotlin and Android code but does not invoke them.

It also points Kotlin Multiplatform projects at KMP Code Quality but does not invoke it.

Invoked by

  • Code — Step 3 and 7, quality baseline and final comparison for Java, Spring Boot and Java Quarkus, via the iru-gate-runner agent.

  • Java Code One Task Group — Steps 1 and 3, once per task group’s bucket, via the iru-gate-runner agent, to capture a pre-change baseline covering every class the bucket touches and later diff the post-change result against it.

  • Kotlin Spring Boot Code One Task Group — Step 1 and 3.7, Checkstyle/PMD/SpotBugs when touched modules hold Java, via the iru-gate-runner agent.

  • Quarkus Code One Task Group — Step 1 and 3.7, Java quality baseline and regression check, via the iru-gate-runner agent.

  • Setup Quarkus Service — Step 9, quality gate for Java builds, via the iru-gate-runner agent.

  • Java Spring Boot Code One Task Group — Steps 1 and 3.7, for the Checkstyle/PMD/SpotBugs baseline and the regression diff against it, via iru-gate-runner. Skipped if not installed — and that skip is itself reported, since a bucket validated with no static analysis at all is worth knowing about. SpotBugs findings are treated more seriously than the rest: unlike most Checkstyle rules they describe real defects rather than style.

Related agents

  • iru-gate-runner — calling skills invoke this skill from inside an iru-gate-runner sub-agent they spawn, not inline.

Source

SKILL.md on GitHub — the file this page was generated from.