What's new in Cursor rules for Java 0.16.0?

What is the purpose?

An opinionated, AI-native development workflow for Java Enterprise: reusable Skills, Agents, Commands, and third-party MCP servers combined with a human-in-the-loop model to modernize real-world SDLC practices.

Starting with this release, the project provides a way to express any SDLC action through 3 phases: Plan, Build, and Operate. Software engineers can use this model in user interfaces or terminals when they write a User prompt.

Example:

Build
  /implement-issue
    @robot-tech-lead
      /create-feature-branch
      /create-worktree
      /review-alignment
      @robot-java-coder
      @robot-java-spring-boot-coder
      @robot-java-quarkus-coder
      @robot-java-micronaut-coder
      @robot-no-java

We will go into more detail later, but first, let's review the features that have evolved since the last release:

Enriching the workflow with Commands and Agents, not only Skills
What are the Top 10 Skills from this project in Skills.sh?
Applying Zero Trust with your Agent skills
Improving the approach to test the behavior of Agent Skills
Improving the way to install Agents and Commands
New capabilities for Java Enterprise Frameworks
Increasing engineering awareness with EU regulations

Thanks to our community members in Singapore, Hong Kong, Hanoi, London, and New York. 👋👋👋

Help this project grow: If this project helps your team, become a sponsor.

Enriching the workflow with Commands and Agents, not only Skills

The project started more than a year ago with a set of reusable rules / system prompts. They were useful because teams could point an AI assistant at a consistent body of engineering expectations instead of rewriting the same instructions for every conversation. But as documented in ADR-002, automatic activation through broad .java frontmatter did not scale well: multiple rules could enter the context at the same time, increasing latency, consuming context, and making answers less deterministic. In 2026, with the rise of Skills and continued use of system prompts, evolving into Skills was a natural step. Release 0.16.0 moves further toward connected workflows. Commands become the entry points that a team can run. Agents become the role-specific workers that interpret the task. Skills become the reusable knowledge and procedures each agent applies.

In practice, the operating model now looks like this:

Command -> Agent -> Skills -> Change in your repository

That model is organized around three delivery paths:

Plan
  /create-issue
    @robot-business-analyst
      @043-planning-github-issues
      @044-planning-jira
      @014-agile-user-story
  /create-adr
    @robot-architect
      @030-architecture-adr-general
      @031-architecture-adr-functional-requirements
      @032-architecture-adr-non-functional-requirements
  /create-diagram
    @robot-architect
      @033-architecture-diagrams
  /create-spec
    @robot-tech-lead
      @042-planning-openspec
  /explore-design
    @robot-architect
      @034-architecture-design-exploration
  /review-alignment
    @robot-business-analyst

Build
  /implement-issue
    @robot-tech-lead
      /create-feature-branch
      /create-worktree
      /review-alignment
      @robot-java-coder
      @robot-java-spring-boot-coder
      @robot-java-quarkus-coder
      @robot-java-micronaut-coder
      @robot-no-java

Operate
  /profile
    @robot-java-performance
      @161-java-profiling-detect
      @162-java-profiling-analyze
      @163-java-profiling-refactor
      @164-java-profiling-verify
  /benchmark
    @robot-java-performance
      @151-java-performance-jmeter
      @152-java-performance-gatling

In coming releases, this model will be expanded in different ways, but its pillars are established in this release.

In other projects, you can find useful Skills, Agents, or Commands, but not always a fully connected workflow designed with Java in mind.

What are the Top 10 Skills from this project in Skills.sh?

The project has 106 skills and uses Skills.sh as its main skill registry. It has served 11.0K installs in total. These are the current top 10 skills used by users there:

What is your favorite Skill from this project? You could share it here: https://github.com/jabrena/cursor-rules-java/discussions/804

Applying Zero Trust with your Agent skills

Skills are not ordinary Markdown files. They are executable guidance for AI agents. A skill can tell an agent how to read code, run commands, inspect evidence, write files, install tools, or make a technical recommendation.

That is useful, but it also means generated skills need a zero trust review mindset. In 0.15.0, the project introduced its first validators for generated skills. In 0.16.0, that support has grown into a broader validation stack with multiple independent gates:

MarkdownValidator checks that project documentation and generated Markdown remain parseable and healthy.
skill-check validates the skill package structure.
cisco-ai-skill-scanner scans generated skills recursively with behavioral scanning and a strict policy.
SkillSpector adds another static quality and security review.
Snyk Agent Scan adds supply-chain and prompt-risk signals.

The point is not to claim that a generated skill is perfect. The point is to make suspicious behavior visible before maintainers or users rely on it.

Common risks include:

Prompt injection patterns
Data exfiltration instructions
Suspicious command execution
Hidden or obfuscated content
Excessive agency
Supply-chain risk
Description-behavior mismatch
Insecure credential handling
System modification and privilege escalation
Untrusted content and indirect prompt injection
Tool poisoning and tool shadowing

If you are interested in this kind of validation, I recommend reading the following article: How to validate skills?

Improving the approach to test the behavior of Agent Skills

All elements in this project change for different reasons, so it is necessary to invest time in the release process to ensure that they continue adding value for software engineers and AI agents running in pipelines.

During this release, we ran a Spike to validate an improved testing process. We added Gherkin support for all skills created or updated in this release, reducing testing time and generating evidence for specific deterministic behaviors.

Let's review 2 examples to show the value of the new tests.

Example to validate a skill

All skills have an acceptance-test inventory, and it lives in acceptance-tests-prompts-skills.md. When a generated skill changes for any reason, it is now possible to run only the matching prompt for that changed skill. Let's review the scenario for @111-java-maven-dependencies.

@111-java-maven-dependencies:

The inventory has a prompt to validate the skill:

execute @skills-generator/src/test/resources/gherkin/skills/111-java-maven-dependencies.feature
and verify that acceptance-tests pass.

You can run the following Gherkin file:

Feature: Validate changes from usage of Maven dependencies skill

Background:
  Given the skill "111-java-maven-dependencies"

@acceptance-test
Scenario: Add JSpecify and Error Prone + NullAway to Maven demo
  Given the example project "examples/maven/maven-demo"
  And the example project has a baseline "pom.xml"
  And the folder "examples/maven/maven-demo" has no git changes
  And the dependency selection answers are:
    | question                  | answer                           |
    | code-quality dependencies | JSpecify; Error Prone + NullAway |
    | main project package name | info.jab                         |
  When the skill "111-java-maven-dependencies" is applied to "examples/maven/maven-demo"
  Then "./mvnw validate" succeeds in "examples/maven/maven-demo"
  And the "pom.xml" declares selected dependencies and compiler plugin arguments
  And ".mvn/jvm.config" contains the required JVM arguments
  And "./mvnw clean verify" fails during compile in "examples/maven/maven-demo"
  And the verification failure is accepted because "-Xlint:all" and "-Werror" convert existing warnings into errors
  And any git changes produced during skill execution and verification are reset

For this particular skill, the scenario fixes the example project, the selected dependency answers, the expected pom.xml changes, the expected .mvn/jvm.config changes, the validation command, the accepted compiler failure, and the cleanup expectation. The goal is not to test every possible conversation. The goal is to prove that the changed skill still follows its intended workflow against a stable fixture.

Let's review another, more complex scenario.

Example to validate a command

All commands have an acceptance-test inventory, and it lives in acceptance-tests-prompts-skills.md. When a generated command changes for any reason, it is now possible to run only the matching prompt for that changed command. Let's review the scenario for @/implement-issue.

As example, lets try to solve the first problem from the project Latency problems: https://github.com/jabrena/latency-problems/blob/master/docs/problem1/README.md

# Problem 1

## User Story Statement

- **As an** API consumer / data analyst
- **I want to** consume God APIs (Greek, Roman & Nordic), filter gods whose names start with a requested letter, convert each filtered god name into a decimal representation, and return the sum of those values
- **So that** I can perform cross-pantheon analysis and aggregate mythology data for research, reporting, or educational applications.

**Notes:**

- Decimal conversion: For each god name, each character is converted to its Unicode integer value and those integers are concatenated as strings (for example, `Zeus` -> `90101117115`). The final result is the numeric sum of all per-name string representations.
- Case sensitivity: The `filter` parameter accepts exactly one Unicode code point and matching is case-sensitive. The documented source data returns god names with uppercase initial letters, such as `Nike`, `Nemesis`, `Neptun`, and `Njord`, so `filter=N` is the meaningful value for the documented aggregate examples. A lowercase `filter=n` is valid but returns no matches for the current documented data.
- HTTP timeouts: Outbound calls use Spring `RestClient` with connect/read timeouts set once in configuration (defaults in `application.yml`; optional environment variable overrides). There is no automatic retry of failed or timed-out requests; aggregation continues with the sources that return in time.
- Configuration: Single default configuration with environment variable overrides for operational flexibility.
- Data sources:
  - Greek API: https://my-json-server.typicode.com/jabrena/latency-problems/greek
  - Roman API: https://my-json-server.typicode.com/jabrena/latency-problems/roman
  - Nordic API: https://my-json-server.typicode.com/jabrena/latency-problems/nordic

Given this User story and the OpenSpec change defined here: https://github.com/jabrena/cursor-rules-java/tree/main/examples/openspec you could be able to implement using the new command /implement-issue. Lets see how to do it and how to validate it.

/implement-issue:

Using this prompt:

execute @skills-generator/src/test/resources/gherkin/commands/implement-issue.feature
and verify that acceptance-tests pass.

You can run the following Gherkin file:

Feature: Validate implement-issue command with the God Analysis API OpenSpec example

Background:
  Given the command prompt file ".cursor/commands/implement-issue.md"
  And the OpenSpec project path "examples/openspec/god-analysis-api"
  And the OpenSpec change path "examples/openspec/god-analysis-api/openspec/changes/add-god-analysis-api"
  And the implementation target directory "examples/openspec/god-analysis-api/demo"
  And the implementation target directory starts empty except for ".gitkeep"

@acceptance-test
Scenario: Implement God Analysis API from a validated OpenSpec change
  Remark: Acceptance execution must use the implement-issue command contract and must not implement outside the requested demo directory.
  Given the OpenSpec change "add-god-analysis-api" contains "proposal.md", "design.md", "tasks.md", and "specs/god-analysis-api/spec.md"
  And the OpenSpec change is validated with "openspec validate --all" from "examples/openspec/god-analysis-api"
  And the command prompt source ".cursor/commands/implement-issue.md" is read before execution
  When the user executes the prompt "/implement-issue examples/openspec/god-analysis-api/openspec/changes/add-god-analysis-api implement in examples/openspec/god-analysis-api/demo"
  Then the command loads the selected OpenSpec "tasks.md" as the execution contract
  And the command confirms the selected OpenSpec change is current, validated, and internally consistent
  And the command identifies the implementation as a Spring Boot MVC Java service from the OpenSpec design and technology constraints
  And the command routes implementation work through "@robot-tech-lead" and the appropriate Java Spring Boot implementation agent
  And the command reports using the current branch as the isolation strategy before implementation starts
  And all generated implementation files are created under "examples/openspec/god-analysis-api/demo"
  And the implementation provides "GET /api/v1/gods/stats/sum"
  And the implementation covers the documented happy path sum "78179288397447443426"
  And the implementation covers the documented partial timeout sum "78101109179220212216"
  And the implementation rejects missing, empty, multi-character, and invalid query parameters with HTTP 400
  And the implementation does not add WebFlux, WebClient, Rest Assured, Resilience4j Retry, Spring Retry, or custom retry loops for US-001
  And the command runs the focused Maven verification command from "examples/openspec/god-analysis-api/demo"
  And the command marks OpenSpec tasks complete only after their acceptance criteria and verification gates pass
  And the command reports changed files, validation evidence, updated OpenSpec task status, risks, and blockers
  And any git changes produced under "examples/openspec/god-analysis-api/demo" during command execution and verification are reset

Under the hood, this Gherkin file triggers the following set of project elements, which can be located in .agents/** or in other locations depending on your preferred tool and installation method:

Build
  /implement-issue
    @robot-tech-lead
      /create-feature-branch
      /create-worktree
      /review-alignment
      @robot-java-coder
      @robot-java-spring-boot-coder
      @robot-java-quarkus-coder
      @robot-java-micronaut-coder
      @robot-no-java

In this case, the command internally uses the agent @robot-tech-lead, which redirects to the specific agent @robot-java-spring-boot-coder based on the analysis of the specification and this is the result:

Running the test with Codex CLI for the Spring Boot variant

Running the test with VS Code + Codex plugin

But if you refine a bit the prompt, you could implement the requirement in Quarkus:

execute @skills-generator/src/test/resources/gherkin/commands/implement-issue.feature
and verify that acceptance-tests pass. 
Implement it using Quarkus, not Spring Boot, as the default requirement.

In this case, the agent @robot-tech-lead redirects the workload to the specific agent @robot-java-quarkus-coder:

Running the test with Codex CLI for the Quarkus variant

Or, if required, the agent @robot-tech-lead redirects to the specific agent @robot-java-micronaut-coder:

execute @skills-generator/src/test/resources/gherkin/commands/implement-issue.feature
and verify that acceptance-tests pass. 
Implement it using Micronaut, not Spring Boot, as the default requirement.

And the project will implement the feature without any issue:

Running the test with Codex CLI for the Micronaut variant

So, it you observe one of the unique features from this project is the capacity to implement requirements in multiple Java frameworks.

Improving the way to install Agents and Commands

With the rise of Skills, there is a need for public registries for them. But what happens with Agents, Commands, or other files? The reality is that Agents and Commands are often treated as second-class citizens.

To take advantage of the public registry and the process for generating skills from XML sources, it is relatively easy to embed commands and agents in a Meta Skill. Once you have installed the skills, you can see the following inventory and installation workflows:

Then you can use them to install assets or generate the inventory files.

New capabilities for Java Enterprise Frameworks

In this new release, we have added a few new Java framework capabilities:

Project creation: starter skills for Spring Boot, Quarkus, and Micronaut, helping teams bootstrap Maven-based services with the expected Java version, framework baseline, package structure, and verification commands from the first commit: @300-frameworks-spring-boot-create-project, @400-frameworks-quarkus-create-project, @500-frameworks-micronaut-create-project.
Spring Modulith: dedicated guidance for modular monolith design with Spring Boot: @305-frameworks-spring-boot-modulith.
MongoDB migrations: Mongock migration skills for Spring Boot, Quarkus, and Micronaut: @316-frameworks-spring-mongodb-migrations-mongock, @416-frameworks-quarkus-mongodb-migrations-mongock, @516-frameworks-micronaut-mongodb-migrations-mongock.

The value is that teams can pick the framework lane first, then apply the matching skills for project creation, REST APIs, validation, security, persistence, messaging, migrations, MongoDB, and tests. If you use one of the main Java frameworks, you can review the following skills:

Spring Boot skills:

Quarkus skills:

Micronaut skills:

Increasing engineering awareness with EU regulations

EU regulations are becoming part of the daily software engineering context, not something that only appears at the end of a release. Modern Java systems process personal data, integrate third-party services, expose APIs, run distributed infrastructure, and increasingly include AI models, RAG pipelines, agents, tool calling, or generated decision support.

For software development teams, the value is practical: regulations help turn vague risk into reviewable engineering questions. They push teams to identify the system scope, data flows, operational controls, human oversight, audit evidence, incident paths, and ownership boundaries before a change reaches production.

This becomes even more important with GenAI tooling. When prompts, embeddings, generated code, agent actions, and tool calls enter the SDLC, teams need a repeatable way to ask what data is being used, what decisions are automated, what evidence is kept, and which legal, security, privacy, risk, or product owners must review the work.

0.16.0 introduces a new alpha family of regulation engineering review skills:

These skills are engineering review aids. They do not provide legal advice and they do not replace qualified legal, compliance, privacy, security, risk, product, or governance owners.

For distributed systems using GenAI tools, a practical review set is:

EU AI Act when the system uses AI models, LLMs, RAG, AI agents, tool calling, or generated decision support.
GDPR when the system processes personal data in prompts, logs, embeddings, retrieval sources, exports, backups, or generated outputs.
NIS2 when the system supports essential or important services, cybersecurity incident flows, supply-chain dependencies, or critical operations.
DORA when the system supports financial entities, important business services, ICT risk, third-party ICT providers, or operational resilience evidence.
Cyber Resilience Act when a product, library, agent tool, or software component may be distributed as a product with digital elements.
Data Act when the system exposes data access, sharing, portability, cloud switching, connected-product data, or interoperability workflows.
Digital Services Act when the system supports hosting, platforms, marketplaces, content moderation, recommender systems, advertising, or transparency reporting.
Digital Markets Act when the system supports gatekeeper-platform concerns, core platform services, interoperability, data access, ranking, or self-preferencing controls.

If you are interested in this set of skills, I recommend reading the following article: Introduction to EU regulations Part I

Next steps

The next phase is already visible in the v0.17.0 milestone. The backlog continues the same direction as 0.16.0: make agent workflows more useful, more deterministic, and easier to adopt in real teams.

Functionally, the next workstreams are:

Expand executable acceptance coverage for Skills, Agents, and Commands, so important behavior is checked with stable Gherkin scenarios instead of relying only on package shape or manual review.
Add LLM engineering references such as Karpathy's LLM Wiki, so agent and skill guidance can stay closer to widely used mental models for building with language models.
Improve analysis methods, including the hamburger method and the two-step method, so discovery work can become more structured before teams generate ADRs, specs, plans, or implementation tasks.
Extend Maven guidance with JavaMoney support in the Maven plugin workflow, improving how teams introduce money and currency handling into enterprise builds.
Complete the EU regulation review family, so teams can map distributed-system and GenAI decisions against a broader set of engineering evidence patterns.

Enjoy.