What's new in Plinth 0.19.0?

Plinth is an AI-native engineering toolkit for the modern Java Enterprise SDLC, built around reusable Commands, Agents, Skills, and MCP Servers. You can use this project to provide an AI-native workflow to your Java Engineering teams, or just use it to refactor aspects of your project with one of the most popular Agent Skill collections for Java Enterprise development in marketplaces like Skills.sh.

This release focuses on three things. First, a new /onboarding command prepares a repository for issue-driven work, so the workflow introduced in 0.18.0 starts from a known, unambiguous state. Second, requirement discovery gets simpler: the ISO/IEC 25010:2023 quality model becomes a first-class engineering review skill, replacing the two older ADR-based requirement skills. Third, the benchmark reaches Part 2, isolating what the orchestration command adds once a written OpenSpec plan already exists. The idea behind all three is the same one that guided the previous release: "better code generation begins before code generation" — and it also begins with an honest measurement of what each step actually buys. In general, this is a small, operational release covering the period between JCConf 2026 and Devoxx BE 2026.

Thanks to our community members in Des Moines, Singapore, Taipei, Madrid, and Shanghai. 👋👋👋

This article is divided into the following sections:

• Community first!
• What are the top 10 skills from this project on Skills.sh?
• Onboarding a repository before issue-driven work
• Reviewing quality attributes with ISO/IEC 25010:2023
• Comparing Plinth commands with OpenSpec and Spec Kit
• Testing the workflow with a reproducible benchmark, Part 2
• How was the experience in JCConf 2026?
• Do you still have questions about the project?
• Next steps

If you have questions about the project, how to customize it for your team, how to use the skills in daily work, or how to solve tooling issues, use GitHub Discussions.

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

Community first!

In this release, I want to thank Leandro Loureiro and Sangwon Park for contributing benchmark samples. Benchmark Part 2 took roughly 4 weeks to collect samples across Claude Code, Codex, and Grok and to analyze the results, growing from 54 samples in Part 1 to 217 samples in Part 2.

I also want to thank SecurO, the cybersecurity company behind the largest community of ethical hackers in Spain, for their security expertise and the insights that helped improve this project. Many thanks to Javier Juárez Zarruk, Daniel Ximenez, and Arnau Cebrián for the support.

If you would like to participate, review the open issues labeled good first issue, propose improvements, test the workflow with another agent tool, or share your experience in GitHub Discussions.

What are the top 10 skills from this project on Skills.sh?

The Skills.sh registry reports 29.1K installs in total — roughly 48% growth since the 0.18.0 release. Compared with 0.18.0, these are the current top 10 skills among Skills.sh users:

Note: The Skills.sh Search rank column shows the skill's position inside that Skills.sh search category when results are sorted by install count.

Two changes stand out. @122-java-type-design enters the table for the first time, and Spring Boot now has two skills in the top 10 — @301-frameworks-spring-boot-core joins @302-frameworks-spring-boot-rest — which suggests framework-specific guidance is becoming as relevant to users as the core Java skills. @142-java-functional-programming and @128-java-generics leave the top 10 this time, although both remain close behind.

Onboarding a repository before issue-driven work

The 0.18.0 release described a complete command sequence from a raw issue to an archived OpenSpec change. That sequence assumes two things about the repository it runs in: that agents have root guidance describing how the project works, and that there is exactly one OpenSpec project to write changes into. When either assumption fails, the first command in the chain pays the cost — an agent guesses where specifications live, or two OpenSpec directories quietly diverge.

The new /onboarding command makes those prerequisites explicit and establishes:

The command is deliberately conservative. It discovers every openspec directory recursively before touching anything, never modifies an existing AGENTS.md or OpenSpec project, rejects result paths that escape the repository, and never runs its two interactive delegations concurrently. Running it again on an onboarded repository performs no writes and simply reports where the OpenSpec project lives. That makes /onboarding safe to run as the first step on any repository — new or existing — before the rest of the workflow begins.

Reviewing quality attributes with ISO/IEC 25010:2023

The 0.18.0 release introduced /explore-problem, which investigates an issue through five lenses, including @025-quality-attribute-discovery. With that lens in place, two older skills — @031-architecture-adr-functional-requirements and @032-architecture-adr-non-functional-requirements — were covering the same ground through a different entry point. This release removes them: requirement discovery now lives in /explore-problem (@021–@025), and structured quality-attribute review lives in a new skill.

The new @814-regulations-iso-25010 skill runs a structured, repeatable review of a Java enterprise system against the ISO/IEC 25010:2023 product quality model, covering all nine quality characteristics:

It ships with a questionnaire, a report template, examples, and an acceptance prompt, and it produces an engineering review report rather than running an interactive ADR discovery session. Each finding is classified as a confirmed gap, a potential gap, or no identified concern, and is handed to an explicit owner — architecture, product, security, platform, or operations — when it needs a decision beyond engineering review.

Like the rest of the 8xx regulations family, the skill is careful about what it is not: it is not certification advice, a compliance decision, or an audit conclusion. It helps a Java team make quality visible and reviewable, and leaves the formal determination to qualified owners.

In upcoming releases, the skill @814-regulations-iso-25010 will replace @025-quality-attribute-discovery within /explore-problem.

Comparing Plinth commands with OpenSpec and Spec Kit

The 0.18.0 article compared Plinth commands against OpenSpec and Spec Kit phases. 0.19.0 adds /onboarding at the start of that mapping:

/onboarding differs from openspec init and specify init in one important way: it does not just initialize; it also refuses to proceed when the repository is ambiguous. A repository with two OpenSpec projects is reported as technical debt instead of silently getting a third.

Testing the workflow with a reproducible benchmark, Part 2

The 0.18.0 release introduced a benchmark harness under benchmarks/. Part 1 showed one scenario clearly ahead of the rest, but it could not say why, because that scenario changed two things at once: the OpenSpec plan and the orchestration command that executes it.

Part 2 separates them. This release expands the harness with a new direct scenario, a second problem, and v2 solution snapshot metrics:

The number of samples grew roughly fourfold, from 54 in Part 1 to 217 in Part 2.

The results revisit the three hypotheses from Part 1:

• Orchestration reduces rework beyond the written plan — conditionally supported. On the harder Quarkus problem, the orchestrated scenario passed every run with half the average rework of the direct one. On the simpler fan-out problem, the gap closed, while the direct scenario was about 36% faster by median wall time.
• The delegation command drives skill and agent use — supported. With the same plan but no orchestration, runs used half the skills and almost no agents. Richer documents do not pull the library in; the command does.
• Written architecture holds regardless of who executes it — supported. The hexagonal scaffold and its boundary test appeared in 67 of 68 direct runs, because the OpenSpec input spells them out. What neither workflow controls yet is the dependency graph.

The practical conclusion is a more precise recommendation than Part 1 allowed: reach for /implement-spec on integration-heavy work, not by default. That is exactly the kind of statement a benchmark should make possible — not a declaration of a universal winner, but evidence about when each step of the workflow pays for itself.

For the detailed methodology and findings, read Validating Hypotheses About the Plinth Workflow with a Benchmark, Part 2.

In upcoming releases, /implement-spec will be improved to reduce latency.

How was the experience in JCConf 2026?

JCConf 2026 was a one-day conference held in Taipei, and it was an excellent place to learn how people from Taiwan, China, Japan, and other countries in Asia use agentic development daily. I am sincerely grateful to Nicolas Lu and the whole JCConf team for their full support.

The talk went smoothly, and I achieved my goal of raising awareness of a few points teams should consider to avoid production issues when using this kind of tooling. If you didn't attend the talk, you can review the slides.

Do you still have questions about the project?

If you are interested in learning how to apply an AI-native workflow to Java Enterprise development, you can attend the following workshop at Devoxx Belgium 2026.

Agenda (180 min):

• Introduction to Agentic Development
• Run Exercise 1
• Break
• Run Exercise 2
• Advanced concepts
• Q&A

Plinth Workflow:

/onboarding
  |
  v
Issue
  |
  v
/update-issue --> /explore-problem --> /create-acceptance-criteria
  |
  v
/create-spec --> /explore-design
  |
  v
/implement-spec
  |
  v
/close-spec

The workshop shows how agents implement changes faster. But a green PR can still be wrong: code that compiles, passes tests and security scans, and meets its acceptance criteria can break production when the consequences live outside the repository. A rename like customerId → clientId is locally correct, yet it can ripple through OpenAPI clients, Kafka events, Flyway migrations, and data pipelines. Implementation speeds up; context and review capacity do not.

If you want to go beyond the green PR, the talk explains why Human-in-the-Loop (HITL) is still required and how to make it meaningful rather than human-as-a-button. It walks through PR gates, shows how laws, standards, and frameworks such as the EU AI Act, GDPR, CRA, NIS2, and DORA become engineering controls, and closes with steps a team can apply next Monday. Agents may propose; accountable humans decide. Join the talk The Importance of HITL to Avoid Chaos and EU Regulations for AI at Devoxx BE 2026.

Next steps

For the next release, we plan to work on a few topics:

• Reduce the latency of /implement-spec on simple problems, as suggested by the Part 2 benchmark.
• Add Katas that help users learn Plinth incrementally.
• Add support for agent plugins.
• Go deeper into the EU regulation ecosystem for GenAI.