SkillsJars: agent skills as versioned Maven artifacts

IntelliJ IDEA Conf ran online and free on September 8 and 9, and the item on the agenda I would have paid for is the smallest one: Agent Skills in IntelliJ IDEA, and a project called SkillsJars. The idea is almost boring, which is why it will work. You package an AI agent skill into a JAR and publish it to Maven Central. From that moment it is a Maven or Gradle dependency like any other: versioned, with transitive dependencies, subject to the same security scanning as your libraries. A Maven plugin extracts the skill onto the filesystem so that assistants such as Claude Code or Cursor can pick it up.

That moves skill distribution from ad-hoc repositories and copied markdown files to infrastructure every JVM team already runs. Whoever controls the distribution channel for skills ends up controlling how agents work inside a company, and JetBrains just proposed that the channel be the one they already sit in.

What a skill is, and why packaging it matters

A skill, in the sense Claude Code and its peers use the word, is a bundle of instructions, optional scripts and reference files that teach an agent to do one thing well: run your release process, follow your migration conventions, review against your style rules. Today those live in a repo folder or a personal dotfiles directory. They drift. Two developers on the same team run different versions and get different agent behaviour, and nobody can say which one the CI agent used.

Put the same bundle in a JAR with a version number and the questions answer themselves. You pin it. You upgrade it deliberately. Your dependency scanner sees it. If a skill pulls in a helper from another skill, that is a transitive dependency and the resolver handles it.

A skill you cannot pin is a prompt someone edited on a Tuesday. A skill on Maven Central is a dependency you can audit.

The supply-chain angle cuts both ways

Maven Central is a mature registry with signing and provenance requirements, and JVM dependency scanning is the best in the industry. Putting skills there inherits that. It also inherits the threat model. A skill is instructions an agent will follow with whatever permissions the agent has. A malicious or merely careless skill, pulled transitively, is a prompt injection with a version number. The security scanning JetBrains mentions is necessary; it is not sufficient until scanners understand what an instruction file can make an agent do.

• Pin exact versions, never ranges, for anything that reaches an agent.
• Review skill diffs on upgrade the way you would review a build plugin, because that is what it is.
• Scope the agent so a bad skill can only reach what the current task needs.
• Keep an allow-list of publishers. Central is open; your build does not have to be.

Where JetBrains is going with this

Read alongside the rest of the 2026.2 cycle it is a coherent direction. IDEA 2026.2.2 landed during the conference with 140 fixed freezes and a Spring Modulith fix; the 2026.2 line shipped day-one Java 27 and Kotlin 2.4. The IDE is stable enough that the interesting work is in how agents plug into it. JetBrains' own agent already consumes MCP, as I covered in Junie and MCP, and the comparison in AIR vs Junie shows two agents that both need a way to receive team conventions. SkillsJars is that way, and it is deliberately not tied to JetBrains' agent: the extraction plugin targets Claude Code and Cursor by name.

For a JVM team the practical move is small. Take the one skill you already trust, the release checklist or the migration guide, package it, publish it to your internal Nexus or Artifactory first, and wire the extraction plugin into the build. If that works, Central is one config change away.

The honest limitation

SkillsJars was presented at a conference, and what I have is the announcement and the project description, not a production deployment or a security review. The format may change before it stabilizes, the extraction plugin's behaviour with skill formats other than Claude Code's is unstated, and "security scanning" today means scanning the JAR, not the semantics of the instructions inside it. Treat this as a direction worth prototyping on an internal registry, not a standard to build a company's agent workflow on yet.