What's new in Plinth 0.17.0?

Plinth is an AI-native engineering toolkit for modern Java enterprise SDLC, built around reusable Commands, Agents, Skills, and MCP Servers.

This release brings several improvements to the development workflow, but the most visible change is the new project identity: the repository moves from cursor-rules-java to plinth.

Thanks to our community members in Urumqi, Singapore, Des Moines, Bengaluru, and San Jose. 👋👋👋

Why Plinth?

In civil architecture, a Plinth is the base that supports what people actually see. It is not the column, the arch, the road, or the aqueduct, but without a good plinth, the visible structure loses alignment, load-bearing capacity, and long-term stability. That image fits the project better than the original name.

The project is no longer only a collection of Cursor rules for Java. Today, it includes Commands, Agents, Skills, generated inventories, OpenSpec workflows, validation pipelines, regulation review aids, framework-specific guidance, and release assets. The new name, Plinth, gives the project a broader identity without losing its Java roots.

The metaphor comes from classical Roman architecture. In the Roman Empire, durable engineering depended on foundations, proportions, materials, load paths, maintenance, and repeatable methods. Marcus Vitruvius Pollio described architecture around the enduring qualities often summarized as firmitas, utilitas, and venustas.

That is a useful analogy for modern software engineering with AI.

An AI agent can generate code quickly, but speed is not enough. A team still needs a stable base: requirements, design constraints, compatibility strategy, tests, security checks, architecture boundaries, operational evidence, and human review. Without that base, the generated work may look impressive while resting on weak assumptions.

Now that the repository name change has been explained, let's continue by reviewing the new features included in this release:

• Community first!
• What are the Top 10 Skills from this project in Skills.sh?
• Design skills for safer delivery
• Comparing Plinth commands with OpenSpec and Spec Kit
• Improving migration safety with Flyway, Mongock, and Parallel Change
• Making architecture boundaries visible with Hexagonal Architecture
• Modeling the domain with stronger Java types
• Extending EU regulations and ISO engineering review skills
• Improving security gates in the pipeline with VirusTotal
• Recommended Books and Talks for this summer
• 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!

As Plinth grows from a technical repository into an OSS product that helps make everyday engineering work easier, the community becomes part of the product itself. Feedback, issue reports, pull requests, and real project stories help keep the guidance practical, reviewable, and useful beyond my own context. This release is a good reminder of that. Many thanks to Leandro Loureiro and Sangwon Park for your contributions.

Leandro expanded the planning workflow with the new @045-planning-azure-devops skill, making it possible to capture what the business tentatively wants to build from issues registered in Azure DevOps. This brings Azure DevOps into the same planning family as @043-planning-github-issues and @044-planning-jira, helping teams start from the tools where their work is already tracked.

Sangwon strengthened the design toolset with the new @057-design-feature-toggles skill. This contribution helps teams introduce feature toggles with clearer design guidance, so they can evolve systems incrementally, reduce release risk, and keep unfinished work under control.

If you use the project, you can participate as an individual contributor: the 0.18.0 backlog already includes new issues labeled with good first issue. You can also share your experience in GitHub Discussions.

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

The Skills.sh registry reports 119 skills and 14.5K installs in total. Compared with the 0.16.0 release article, these are the latest top 10 skills used by Skills.sh users:

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

The same view for framework-specific skills shows the top 5 project skills for Spring Boot, Quarkus, and Micronaut searches:

Spring Boot

Quarkus

Micronaut

Note: The project is currently consolidating the Skills.sh data from cursor-rules-java to plinth: https://www.skills.sh/jabrena. There is an open ticket for this work: https://github.com/jabrena/plinth/issues/975

If you use the project but you have doubts about any Skill, you could share your feedback in GitHub Discussions.

Design skills for safer delivery

AI coding tools are very good at producing code quickly. That is useful, but speed alone is not the same as engineering discipline. Real delivery work also needs design sequencing, compatibility analysis, test strategy, small slices, and reviewable evidence.

This release adds a new family of design skills to be used in the workflow:

• @051-design-two-steps-methods
• @052-design-hamburger-method
• @053-design-simple-rules
• @054-design-tdd
• @055-design-parallel-change
• @056-design-avoid-breaking-changes

Repeat with me:
“SDD is not Aladdin’s lamp—it won’t grant every software wish”.

Once the OpenSpec change is created, the next step is to refine it with design skills before implementation begins. The spec describes the intent, but the design skills help shape the change into a safer engineering path: smaller slices, clearer compatibility decisions, stronger test strategy, and explicit review points.

"There is no favorable wind for the sailor who doesn’t know where to go”
― Seneca

Invest quality time in gathering and refining the requirements that belong in the spec. The design phase should move deliberately at 1x; once the spec is clear, implementation can safely accelerate toward 10x because the intent, constraints, and verification path are already understood.

Continue running Three Amigos sessions to combine business, technology, and quality perspectives before implementation starts.

If you are interested in this new set of design skills, I recommend reading From code generation to software engineering.

Comparing Plinth commands with OpenSpec and Spec Kit

Plinth commands make software engineers' lives easier by hiding the tool-specific details of the SDD workflow. The comparison below shows how those commands map to OpenSpec and Spec Kit phases, from intake to specification, design refinement, task planning, and implementation.

Looking deeper into the command execution details, we can see the relationship between Plinth commands and Plinth agents:

In future releases, the agents related to Analysis & Design will become more independent to increase decoupling between phases. For example, /create-spec currently maps to @robot-tech-lead. Starting in release 0.18.0, @robot-tech-lead will participate only in implementation phases. This change will make the project more modular and easier to customize for your organization.

Improving migration safety with Flyway, Mongock, and Parallel Change

Database migrations are one of the easiest places for an AI agent to produce a clean-looking but unsafe patch. Bad migrations can damage a database in ways that are hard to recover from:

• A column is renamed in place while old application instances are still running, so writes start failing during a rolling deployment.
• A column is dropped because the new code no longer uses it, but a delayed worker, report, export, or integration still reads it.
• A backfill updates every row with the wrong default, overwriting meaningful historical data with a value that cannot be reconstructed.
• A migration changes money, time-zone, status, or identifier semantics without preserving the original business meaning.
• A NOT NULL, unique, or foreign-key constraint is added before dirty production data has been measured and cleaned.
• A long-running DDL statement locks a hot table and turns a small schema change into an availability incident.
• A MongoDB document migration rewrites nested fields without handling old variants, partial documents, or unknown enum values.
• A rollback restores the previous application version, but the destructive migration has already removed the shape that version needs.

This release improves the migration guidance for:

• @313-frameworks-spring-db-migrations-flyway
• @413-frameworks-quarkus-db-migrations-flyway
• @513-frameworks-micronaut-db-migrations-flyway
• @316-frameworks-spring-mongodb-migrations-mongock
• @416-frameworks-quarkus-mongodb-migrations-mongock
• @516-frameworks-micronaut-mongodb-migrations-mongock

The new guidance emphasizes migration safety, antipatterns, and Parallel Change.

This is why @055-design-parallel-change belongs in the design workflow before framework-specific Flyway or Mongock implementation guidance. The agent should understand the transition before it writes the migration.

⚠️ AVOID RUNNING DATABASE MIGRATION TASKS WITHOUT HITL.
Human-in-the-loop review is necessary because migrations can destroy or reinterpret production data, block critical tables, break rollback paths, and affect systems that are not visible in the local codebase. An agent can draft the plan, checks, and scripts, but a qualified human owner should review the migration intent, data impact, rollback strategy, monitoring evidence, and execution window before it reaches production.

Note: If your domain or subdomain owns microservices with associated databases and you are adopting GenAI tools, you should review the current architecture to mitigate potential production database issues.

If you want to go deeper into this topic, I recommend reading: Why Do I Need to Use the Parallel Change Pattern?

Making architecture boundaries visible with Hexagonal Architecture

This release adds @707-technologies-hexagonal-architecture, a framework-agnostic skill for implementing Hexagonal Architecture in your applications.

As Alistair Cockburn defines it in the original article:

The hexagonal architecture, or ports and adapters architecture, is an architectural style used in software design. It aims at creating loosely coupled application components that can be easily connected to their software environment by means of ports and adapters.

The skill helps engineers and agents inspect whether dependency direction and responsibility placement are consistent with Hexagonal Architecture:

• Domain code should not depend on framework adapters.
• Application services should coordinate use cases without becoming infrastructure code.
• Adapters should translate between external systems and the application boundary.
• Framework-specific details should stay outside the core model unless the team has made an explicit tradeoff.

The skill also includes ArchUnit-aware verification guidance without forcing every project to add a new dependency automatically. That is important because architecture tests should support the existing project context, not become cargo-cult configuration.

Example:

@ArchTest
static final ArchRule should_keep_application_core_independent_from_adapters = noClasses()
        .that()
        .resideInAnyPackage("info.jab.domain..", "info.jab.mv.application..")
        .should()
        .dependOnClassesThat()
        .resideInAPackage("info.jab.mv.adapter..");

@ArchTest
static final ArchRule should_keep_domain_independent_from_application_services = noClasses()
        .that()
        .resideInAPackage("info.jab.mv.domain..")
        .should()
        .dependOnClassesThat()
        .resideInAPackage("info.jab.mv.application..");

@ArchTest
static final ArchRule should_keep_driving_adapters_independent_from_driven_adapters = noClasses()
        .that()
        .resideInAPackage("info.jab.mv.adapter.in..")
        .should()
        .dependOnClassesThat()
        .resideInAPackage("info.jab.mv.adapter.out..");

@ArchTest
static final ArchRule should_keep_driven_adapters_independent_from_driving_adapters = noClasses()
        .that()
        .resideInAPackage("info.jab.mv.adapter.out..")
        .should()
        .dependOnClassesThat()
        .resideInAPackage("info.jab.mv.adapter.in..");

For curious users, take a look at the ArchUnit documentation here: https://www.archunit.org/userguide/html/000_Index.html

For framework agents, the skill is useful before making changes in Spring Boot, Quarkus, or Micronaut applications. It gives the agent a boundary review language before it starts moving packages, introducing adapters, or changing service responsibilities.

Modeling the domain with stronger Java types

Java is a strongly typed programming language, and that is not only a compiler detail. It is one of the main design tools available to a Java team. Good types make business rules visible, prevent accidental misuse, improve method signatures, and help agents reason about the code before they change it.

This matters especially when a domain concept has more meaning than its storage representation. A String can hold an email, an order id, a country code, or a currency code, but those values are not interchangeable. A BigDecimal can hold a numeric amount, but it does not explain whether the amount is euros, dollars, tax, discount, revenue, balance, or an exchange rate. When everything is modeled with generic types, invalid combinations become easier to write and harder to review.

For that reason, @111-java-maven-dependencies now includes JavaMoney guidance. The skill helps agents recognize when a project should use Money and Currency API support, including JSR 354 and Moneta, instead of treating monetary values as isolated numbers.

This update combines well with @122-java-type-design, which focuses on type-safe wrappers, domain-specific value objects, and reducing primitive obsession in Java code.

Use this guidance when a project needs to model money, currencies, amounts, exchange-rate concerns, pricing, billing, financial calculations, or financial domain values where BigDecimal alone is too weak to describe the business meaning. The goal is not to add dependencies by default. The goal is to choose types that make the model harder to misuse and easier to evolve.

Extending EU regulations and ISO standard engineering review skills

0.16.0 introduced the first family of EU regulation engineering review skills. 0.17.0 extends that family with financial-market, market-integrity, product-liability, and AI management-system review support:

• @810-regulations-eu-mifid-ii
• @811-regulations-eu-market-abuse-regulation
• @812-regulations-eu-product-liability-directive
• @813-regulations-iso-42001

These skills include questionnaires, report templates, examples, and acceptance prompts.

The common workflow is:

1. Classify whether the system, product, workflow, or AI capability is in scope.
2. Ask for concrete engineering evidence.
3. Map regulatory or standard concerns to controls, logs, tests, approvals, documentation, and release gates.
4. Produce a report for qualified owner review.

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

For fintech and enterprise teams, the practical value is early evidence. An AI agent working on trading workflows, issuer disclosure, surveillance alerts, product updates, model governance, RAG systems, or AI-assisted delivery should know which engineering questions may need owner review before release.

The current regulation and standard review coverage is:

If you are interested in this topic, I recommend reading both articles: Introduction to EU regulations Part I and Introduction to EU regulations Part II

Improving security gates in the pipeline with VirusTotal

This release also strengthens the validation path around generated content, release artifacts, and documentation.

The pipeline now includes VirusTotal checks before generated artifacts are promoted. In the latest scan, VirusTotal evaluated the artifact with 75 security applications and engines. This is not a replacement for the build, tests, or human review, but it gives maintainers one more piece of evidence when deciding whether a generated artifact is ready to publish.

The scan included the following applications and engines: ALYac, APEX, AVG, Acronis, AhnLab-V3, Alibaba, Antiy-AVL, Arcabit, Avast, Avast-Mobile, Avira, BitDefender, BitDefenderFalx, Bkav, CAT-QuickHeal, CMC, CTX, ClamAV, CrowdStrike, Cylance, Cynet, DeepInstinct, DrWeb, ESET-NOD32, Elastic, Emsisoft, F-Secure, Fortinet, GData, Google, Gridinsoft, Ikarus, Jiangmin, K7AntiVirus, K7GW, Kaspersky, Kingsoft, Lionic, Malwarebytes, MaxSecure, McAfeeD, MicroWorld-eScan, Microsoft, NANO-Antivirus, Paloalto, Panda, Rising, SUPERAntiSpyware, Sangfor, SentinelOne, Skyhigh, Sophos, Symantec, SymantecMobileInsight, TACHYON, Tencent, Trapmine, TrellixENS, TrendMicro, TrendMicro-HouseCall, Trustlook, VBA32, VIPRE, Varist, ViRobot, VirIT, Webroot, Xcitium, Yandex, Zillya, ZoneAlarm, Zoner, alibabacloud, huorong, tehtris.

Recommended Books and Talks for this summer

Specifications:

Specification by Example, by Gojko Adzic, is a fantastic book for learning how to turn real examples into clear, testable specifications that business and engineering teams can share.

For a software engineer, the value of this book is very practical. It teaches how to move from vague requirements to concrete examples that expose ambiguity before code is written. That habit improves conversations with product owners, helps developers discover edge cases earlier, and gives testers a stronger basis for acceptance criteria.

It is also a useful book for teams adopting AI coding tools. Agents work better when the expected behavior is described with precise examples instead of broad intentions. A good example can become a shared requirement, a test case, a review checklist, and a prompt input. That makes the delivery workflow more explicit and reduces the risk of generating code that looks correct but solves the wrong problem.

Spec-Driven Development:

I recommend watching one of the recent talks from Simon Martinelli about Spec-Driven Development. I appreciate the common sense in his ideas.

The useful message for engineers is that a specification is not paperwork created after the real work is done. A good spec describes the use cases, business rules, examples, constraints, and acceptance expectations that should guide implementation. When the use cases are explicit, developers can reason about behavior before choosing frameworks, persistence details, or API shapes.

Empirical Software Design:

For daily design discipline, I recommend Tidy First? by Kent Beck. The book is short, practical, and focused on small structural improvements that make the next behavior change easier.

Its value for software engineers is the distinction between tidying and changing behavior. Before adding a feature, fixing a bug, or asking an agent to modify code, sometimes the best first move is a tiny design improvement: clarify a name, separate a responsibility, remove a little duplication, or make a dependency direction easier to see. Those small moves reduce risk without turning every change into a refactoring project.

LEAN Development:

If you are interested in improving your LEAN skills, Eduardo Ferro has published an excellent book:

Menos software, más impacto is especially useful for engineers who feel their team is running faster but delivering less real value. The book frames software as something that must be cultivated, not merely built once and forgotten. Every feature, integration, dependency, and line of code creates a permanent maintenance cost, even when nobody is actively changing it.

The practical lesson is close to the spirit of this release: good engineering is not only about generating more code. It is also about protecting team capacity through active simplicity, reducing work in progress, removing unused functionality, building quality from the beginning, and choosing what not to build. That mindset is healthy for human teams and even more important when agents can produce large amounts of code very quickly.

Hexagonal Architecture:

If you are interested in Hexagonal Architecture, I recommend Alistair Cockburn's book:

Hexagonal Architecture, also known as Ports and Adapters, is valuable because it protects the application core from accidental dependency on external technologies. The business behavior should not be trapped inside a web controller, a database repository, a message broker consumer, or a framework callback. Instead, the application exposes ports that describe purposeful conversations, and adapters translate between those ports and the outside world.

That separation gives engineers several practical benefits: use cases can be tested without a real UI or database, adapters can be replaced when technology changes, and architecture reviews can focus on whether business logic is leaking across the boundary. For teams using AI agents, this is especially important. A clear inside/outside boundary gives the agent a better map of where domain behavior belongs and where framework-specific code should stay.

If you use the project and have nice books to share that fit this engineering direction, share your recommendations in GitHub Discussions.

Next steps

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

• Add Katas that help users learn Plinth incrementally.
• Improve behavior across the Design phase.
• Decouple agents for design and implementation.
• Make the project more modular so it is easier to integrate into organizations.
• Update the Spring Boot support for 4.1.0.
• Add a skill about JVM Flags.
• Go deeper into the EU regulation ecosystem for GenAI.