Plinth for Java: an AI-native SDLC toolkit built from Commands, Agents and Skills

The problem Plinth addresses: Java enterprise work has no written path from issue to merged spec

Most Java teams already have the tooling: Maven, a framework, a test runner, a linter. What they do not have is a repeatable sequence that turns a ticket into an accepted design and then into code, with the intermediate artefacts written down. Plinth's answer is to encode that sequence as slash commands that an AI coding agent executes. The README states the goal plainly: "An opinionated AI-native workflow for evolving modern Java Enterprise SDLC practices through reusable Skills, Agents, Commands & MCP servers."

The audience is narrow and identifiable. It is a Java team that has already given its developers an agent (Cursor, Claude Code, Codex, or GitHub Copilot) and now wants those agents to follow a shared process instead of improvising per developer. The project counts 13 Commands, 9 Agents and 125 Skills, and the skills are not generic prompt files: the README lists guidance for Spring Boot, Quarkus, Micronaut, OpenAPI, WireMock, Maven, profiling, benchmarking and regulation review. That breadth is the pitch. It is also the thing to scrutinise, because 125 skills is a lot of surface area to keep coherent across four different agent clients.

How the workflow actually chains: issue, functional spec, acceptance criteria, OpenSpec change, implementation

The mechanism is a linear command pipeline, and the README draws it as a diagram rather than describing it in prose. It starts with /onboarding, which the README says "establishes root AGENTS.md and one unambiguous OpenSpec project before issue selection." That ordering matters: the agent is given repository-level guidance and a single OpenSpec project before it is allowed to touch a ticket. The README notes that /onboarding preserves existing prerequisites and, when OpenSpec is missing, asks you to pick a result path with documentation/openspec as the default.

From there the chain is /update-issue, then /explore-problem, then /create-acceptance-criteria. The last of these derives Gherkin acceptance criteria from a Functional Specification and posts them as a separate issue comment, so the artefacts land on the issue tracker rather than in a local scratch file. /explore-problem evaluates the issue from five perspectives and posts a Functional Specification comment. Optional steps sit alongside: /create-adr records a decision with alternatives and consequences, /create-diagram produces a diagram from approved artefacts, /create-spec creates or updates validated OpenSpec changes, and /explore-design compares technical approaches for an approved direction. Implementation is /implement-spec, described as delivering an approved plan or validated OpenSpec task list "through framework-aware delegation", and /close-spec archives an OpenSpec change by name using the OpenSpec CLI.

Two things stand out. First, the pipeline depends on OpenSpec as an external tool; Plinth orchestrates it rather than replacing it. Second, the operate and compliance commands sit outside the main chain: /profile coordinates Java profiling from baseline detection to verified optimisation, /benchmark selects between JMeter, Gatling and JMH, and the regulation skills cover the EU AI Act, DORA, GDPR, NIS2 and the Cyber Resilience Act. The README marks the compliance set as Alpha and states that those skills "support engineering awareness and do not provide legal advice." Treat that label literally.

Installing Plinth for Cursor, Claude Code, Codex or GitHub Copilot

The README gives a "Start in 60 seconds" section. Skills install through the skills CLI, with one command per agent. The wildcard installs every skill in the repository:

npx skills add jabrena/plinth --skill '*' --agent cursor -y
npx skills add jabrena/plinth --skill '*' --agent claude-code -y
npx skills add jabrena/plinth --skill '*' --agent codex -y
npx skills add jabrena/plinth --skill '*' --agent github-copilot -y

Pick the line matching your agent. The README shows these as separate commands rather than one loop, so there is no ambiguity about which agent receives the files.

Commands and agents install differently, through Plinth's own installation commands rather than npx. The README shows the command form first:

install @004-commands-installation cursor
install @004-commands-installation claude-code
install @004-commands-installation codex
install @004-commands-installation github-copilot

Agents use the parallel command @005-agents-installation with the same agent argument, and the README presents that block as plain text rather than a shell block, which suggests it is typed into the agent's own command surface. That distinction is worth checking against your client before you run anything, because the README does not spell out where each form is entered.

The first real use is /onboarding. Run it before selecting an issue, since the README's ordering places repository guidance and OpenSpec project selection ahead of issue work. What you should expect to see afterwards is a root AGENTS.md and a single OpenSpec project, with documentation/openspec as the default path when OpenSpec was not already present. If your repository already has OpenSpec configured, the README says existing prerequisites are preserved, so /onboarding should not overwrite them.

Where Plinth gets in the way: rollback, scope and the four-client problem

The README documents installation in detail and says nothing about removal. There is no uninstall command, no list of files that npx skills add writes, and no note on what happens to a root AGENTS.md that /onboarding created if you later abandon the workflow. For a toolkit that installs into version-controlled repositories across four different agent clients, that is a real gap. You can inspect the repository layout to work out where things land, but the documentation itself is silent, and that silence should shape how you trial it: on a branch, not on main.

The second constraint is that Plinth is not standalone. Every entry point is a slash command or a skill consumed by an external agent, and the main pipeline additionally depends on OpenSpec and on an issue tracker (GitHub Issues, Jira or Azure DevOps). If your team has not standardised on an agent, Plinth has nothing to attach to. The 125 skills also mean a large amount of guidance text enters your agent's context; the README gives no guidance on installing a subset, beyond the wildcard form, so selective adoption is something you would have to work out from the skills directory yourself.

Third, the compliance skills are labelled Alpha and explicitly disclaim legal advice. Regulation-aware engineering controls are a reasonable thing to automate at the level of checklists and evidence, but an Alpha skill set mapped to the EU AI Act, DORA, GDPR, NIS2 and the Cyber Resilience Act should not be the artefact your compliance function relies on. Use it to prompt the right questions, not to answer them.

Plinth compared with plain AGENTS.md files and hand-written prompt libraries

The obvious alternative is what most Java teams do today: a root AGENTS.md or CLAUDE.md with project conventions, plus a folder of prompt snippets each developer maintains privately. The difference is structural. Hand-written guidance is a document; Plinth is a state machine. Commands like /create-acceptance-criteria and /close-spec have defined inputs, defined outputs and a defined place to put them (an issue comment, an OpenSpec change). A prompt library cannot archive a change by name, because it has no concept of a change.

The cost of that structure is coupling. A hand-written AGENTS.md survives a change of agent client, because it is just text a human reads. Plinth's commands and agents install per client, with separate commands for cursor, claude-code, codex and github-copilot, so switching clients means reinstalling and re-verifying that the workflow still behaves the same way. If your team is likely to move between agents, or to run different agents on different squads, the plain-file approach degrades more gracefully. If your team has settled on one client and the problem is inconsistent process rather than missing tooling, the command pipeline does something a prompt file cannot.

Maintenance, releases and what the Apache-2.0 licence does and does not cover

The repository is not archived, and the last push was on 2026-09-15, so the project is being worked on. Release cadence is visible in the tags: 0.16.0 on 2026-06-21, 0.17.0 on 2026-07-11, 0.18.0 on 2026-08-02. Three minor releases in roughly six weeks, all still on a 0.x line. For adopters that means two things. Upgrades arrive often enough that you should expect to re-run the install commands rather than treat it as a one-time setup, and the absence of a 1.0 means the command names and skill identifiers have not been declared stable. The repository carries a CHANGELOG, so the upgrade cost is at least inspectable before you pull.

The licence is Apache-2.0. That permits commercial use and modification and includes a patent grant, which is the usual reason enterprises prefer it over MIT for tooling that touches their delivery pipeline. It does not, on its own, settle anything about the output your agent produces, and it says nothing about the regulatory skills: an Apache-2.0 licence on a GDPR checklist does not make that checklist legally sufficient. Those are separate questions, and the README's own disclaimer on the compliance section points the same way.

Editorial conclusion

Adopt Plinth if your team already runs a Java enterprise stack on Cursor, Claude Code, Codex or GitHub Copilot and wants a written path from issue to spec to implementation, because the Commands encode that path rather than leaving it to habit. Do not adopt it if you need a documented uninstall, or if you want a tool that works without an agent installed, since every entry point here is a slash command or a skill file. Before you commit, verify three things in your own repository: that /onboarding produces a root AGENTS.md you are willing to keep, that the OpenSpec project it selects under documentation/openspec is unambiguous when you have more than one, and that the Compliance skills, still marked Alpha, match the regulations your organisation actually falls under.

Frequently asked questions

Official sources

1. jabrena/plinth on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases