Kotlin/kotlin-agent-skills: JetBrains' Skill Pack for Kotlin Coding Agents

The gap these skills fill: Kotlin code that compiles but reads like Java

A general-purpose coding agent knows Kotlin syntax. What it does not reliably know is the set of conventions a Kotlin team expects in a Spring or JPA codebase, or the ordering constraints of a Gradle or AGP upgrade. Those are the two problem areas the repository names. The README defines the backend category as skills covering correct use of Spring, JPA and other backend frameworks with Kotlin, and the tooling category as anything tooling related, with build tooling given as the example. The audience is therefore narrow and specific: teams that already use an Agent Skills compatible coding agent on a Kotlin project and are tired of correcting the same class of mistake. It is not a library, not a Gradle plugin, and not something you add to a build file. Nothing in the README describes runtime code, so a Kotlin project that never invokes an agent gains nothing from cloning it.

What a skill actually is: a folder, a SKILL.md, and YAML frontmatter

The mechanism is deliberately plain. A skill is a self-contained folder holding instructions, scripts and resources for one use case. Each folder contains a SKILL.md file with YAML frontmatter carrying two fields, name and description, followed by the guidance the agent follows while that skill is active. The README points to agentskills.io as the standard behind this format. Two consequences follow from that design. First, the useful content is prose, so the quality of a skill is a writing and accuracy problem rather than an engineering one. Second, because the frontmatter description is what an agent matches against, the description field does real work: it is the routing signal that decides whether the skill loads at all. The repository layout section lists exactly one directory, skills/, which holds every skill. There is no build step, no compiled artifact, and no manifest beyond the per-skill frontmatter.

The naming rule is the closest thing to a schema here

Kotlin-agent-skills enforces a naming convention rather than a code structure: kotlin-<category>-<functional-name>. The category segment comes from a fixed list, and the README names only two, backend and tooling. Adding a category requires opening an issue, which means the taxonomy is controlled centrally by the maintainers rather than by contributors. The functional name is kebab-case and should be short and descriptive. The one skill path the README shows in full is skills/kotlin-tooling-agp9-migration, which parses cleanly under the rule: kotlin, tooling, agp9-migration. That single example also tells you what kind of work these skills encode. An AGP 9 migration is a bounded, versioned, checklist-shaped task, which is the shape a skill handles well. A broad request like write idiomatic Kotlin is the opposite, and the naming scheme gives you no way to express it. If you are writing your own skill for a private fork, follow the same pattern or your folder will not match the convention the rest of the repository uses.

Installing it: three plugin paths and one manual copy

The README gives four routes. The skills CLI is the most agent-agnostic: npx skills add Kotlin/kotlin-agent-skills, with the note that npx skills, a Vercel Labs project, offers more options. For Claude Code there are two commands, claude plugin marketplace add Kotlin/kotlin-agent-skills followed by claude plugin install kotlin-agent-skills@Kotlin. For Codex the sequence is codex plugin marketplace add Kotlin/kotlin-agent-skills, then inside codex invoke /plugins, search for kotlin-agent-skills, press Enter and select Install plugin. The manual route is a plain copy into your agent's skills directory, and the README's example is cp -r skills/kotlin-tooling-agp9-migration .claude/skills/. Notice what the manual example implies: you copy one skill folder, not the whole skills/ directory. That is the right granularity if you only care about the migration skill, and it is also the route that gives you no update path, since a copied folder is a fork the moment you edit it. The plugin marketplace commands are the ones that keep a version relationship with upstream, so prefer them unless you are deliberately pinning a single skill.

Incubator status, no releases, and what that means for pinning

Two signals in the supplied material matter more than any feature description. The README carries a JetBrains incubator badge, and no releases were retrieved for the repository. Together those mean there is no tagged version to depend on and no changelog to read before upgrading. An agent plugin that updates from a marketplace branch can change the instructions your agent follows between one working session and the next, and with no release notes you have no announcement to check. For a team that treats agent behaviour as part of its development process, that is a real operational gap. The practical mitigations are the ones the README already supports: use the manual copy route when you need a frozen skill, or read the SKILL.md diff yourself before accepting an update. The Apache-2.0 licence is permissive and permits modification and redistribution, but the repository does not state a trademark or attribution policy for derivative skill packs, so if you fork and republish under a different name, read the licence text yourself rather than assuming. Nothing here is legal advice.

Where the pack is thin, and the case for a different tool

The honest limitation is coverage. The README documents two categories, backend and tooling, and names one skill path in its installation example. A Kotlin Multiplatform project, an Android UI codebase, or a serverless Kotlin service may find nothing here that applies, and the README gives no inventory to check against beyond browsing skills/ yourself. The second limitation is the format itself. A SKILL.md is guidance the agent reads, not a check that runs. Nothing in the material suggests the skills execute a verifier, so a skill cannot fail a build when the agent ignores it. If you want enforcement rather than suggestion, the alternative is a linter or formatter wired into your build, ktlint or detekt being the usual choices, with rules that break CI on violation. The difference in approach is sharp: a linter encodes a rule as an executable check with a pass or fail result, while a skill encodes a rule as text the model may or may not follow. They are not substitutes. A skill can express judgement a rule cannot, such as the order in which to perform an AGP migration, and a linter can guarantee an outcome a skill cannot. Teams that need guarantees should not expect this repository to provide them.

Maintenance cost and who should wait

The maintenance burden is low but not zero. There is no dependency to update, no Gradle task to keep working, and no service to run. What you maintain is the fit between the skill text and your actual stack. If your project uses a Spring version or an AGP version the skill was not written against, the guidance may be wrong in ways the agent will not flag, because the agent treats the skill as authoritative while it is active. The upgrade cost is the review cost: each time the marketplace pulls a new revision, someone has to read the changed SKILL.md files. For a two-category, incubator-stage pack that is a small amount of reading, which is exactly why it is feasible now and may not stay feasible as the pack grows. The repository invites contributions and points to CONTRIBUTING.md for details, so teams with strong internal Kotlin conventions have a path to encode them upstream instead of maintaining a private fork. Start by listing the folders under skills/, reading the frontmatter description in each SKILL.md, and installing only the skills whose descriptions name frameworks you actually use.

Editorial conclusion

Adopt it if your team already runs Claude Code, Codex or an Agent Skills compatible agent on a Kotlin codebase and you want the agent to follow Kotlin-specific backend and build conventions instead of generic JVM advice. Skip it if you need broad framework coverage today: the README documents two categories, backend and tooling, and no releases were retrieved, so there is no version to pin. Before rolling it out, list the folders under skills/ on the main branch, open the SKILL.md frontmatter in each, and confirm that the description text actually matches the frameworks your project uses. Then install through the marketplace command for your agent rather than copying folders, so updates arrive with the plugin.

Official sources

1. Issues
2. Kotlin/kotlin-agent-skills on GitHub
3. License: Apache-2.0
4. Project website
5. README