This Top 10 Kotlin guide starts with language idioms and structured concurrency, then separates the testing baseline from conditional workflows for Ktor, Exposed, Spring Boot, JPA / Hibernate, coroutines and Flow, native builds, and Apollo GraphQL.
The selection is intentionally direct. kotlin-patterns is the language default, kotlin-testing is the broad Foundation testing baseline, and every other card answers a narrower repository signal. Ktor and Spring Boot are not interchangeable, Exposed and JPA / Hibernate are different persistence models, and coroutines and Flow, native performance, and Apollo GraphQL solve separate jobs. Install counts are integer skills.sh observations captured and labelled for September 2026.
How this list was picked
Language default versus test baseline. kotlin-patterns covers core Kotlin idioms and structured concurrency. kotlin-testing is a broad Foundation for Kotest, MockK, and Kover when testing is the job, not a competing language default.
Four source cap. The catalog uses four ECC cards, one GitHub card, three Kotlin cards, and one card each from Chris Banes and Apollo GraphQL. No source contributes more than the category cap of four.
Conditional technology routing. Ktor, Exposed, Spring Boot, JPA / Hibernate, Kotlin/Native, and Apollo GraphQL each have an explicit conditional label and should be selected from repository evidence. Coroutines and Flow are a core Kotlin specialty.
Source-grounded counts. Every card links to its primary raw SKILL.md source. Install counts are integer skills.sh snapshot observations dated September 2026, rather than unlabelled live totals.
Top 10 Kotlin skills at a glance
A comparative index of the top picks. Click any card to navigate directly to its detailed review.
Install counts are integer skills.sh snapshot observations captured in September 2026. Foundation and Conditional labels explain how each skill should be selected.
Language Defaults and Testing Baseline
Start with the language workflow for ordinary Kotlin changes, then use the broad testing baseline when behavior needs proof. Ktor and Exposed are explicit conditional choices for repositories that already use those technologies.
kotlin-patterns
2.7K installs ECCCore default
Best for: A normal Kotlin implementation, refactor, or language design change
kotlin-patterns is the language-level starting point for Kotlin work. It focuses on idiomatic Kotlin and structured concurrency, giving an agent a baseline for readable implementation before a framework or product workflow is selected.
Use it for ordinary Kotlin source changes and refactors. It is the only broad language default in this catalog, so it should not be displaced by a framework card merely because the project runs on the JVM.
Idiomatic Kotlin language and API patterns
Structured concurrency for coroutine-based work
Language-first decisions before framework conventions
A broad default for implementation and refactoring
Best for: Kotlin unit tests, mocks, and coverage work
kotlin-testing is the broad testing baseline for Kotlin projects. Its workflow uses Kotest for expressive tests, MockK for Kotlin-aware doubles, and Kover for coverage evidence around the behavior under change.
Choose it when testing is the task's center, whether the implementation is plain Kotlin or belongs to a framework. It is a testing foundation, not a framework, toolchain, or product-specific default.
Best for: A Kotlin service that is already built on Ktor
kotlin-ktor-patterns is a Ktor-specific workflow for routing, plugin configuration, and HTTP behavior. It keeps endpoint changes aligned with Ktor's application setup instead of treating a Ktor service as generic Kotlin code.
Load it only when the repository uses Ktor. Use testApplication to verify the route and plugin boundary, while the language and testing baselines remain separate choices.
Best for: Database work in a Kotlin project using Exposed
kotlin-exposed-patterns covers Kotlin Exposed's DSL and DAO approaches, with transactions and migrations treated as part of the persistence change. The workflow keeps database behavior explicit rather than hiding it behind generic Kotlin abstractions.
Select it conditionally when the repository uses Exposed and the task changes tables, queries, entities, or transaction boundaries. It is not a substitute for the separate JPA / Hibernate workflow.
These cards are narrow workflow choices. Confirm Spring Boot, JPA / Hibernate, or an active Java-to-Kotlin conversion before loading the matching instructions, rather than stacking them onto every Kotlin change.
kotlin-springboot
9.7K installs GitHubConditional · Spring Boot
Best for: A Kotlin backend that is already built on Spring Boot
kotlin-springboot is the Spring Boot implementation workflow in this catalog. It focuses on Kotlin-specific Spring Boot configuration and the JPA integration points that shape a backend service.
Use it only when the build and application configuration establish Spring Boot. Do not choose it over Ktor because both are Kotlin; choose the conditional card that matches the service's existing framework.
Best for: An active Java-to-Kotlin conversion or migration audit
kotlin-tooling-java-to-kotlin is a migration workflow, not a general Kotlin style guide. It treats Java-to-Kotlin conversion as an audit: inspect the converted code, check semantics and nullability, and identify changes that need deliberate review.
Load it conditionally for a Java-to-Kotlin migration or conversion review. For new Kotlin code, start with kotlin-patterns instead of introducing migration-specific checks without a Java source to compare.
Best for: Kotlin entity design in a JPA / Hibernate persistence model
kotlin-backend-jpa-entity-mapping handles the Kotlin-specific hazards of JPA entities. Its workflow examines entity lifecycle, equality, and mapping decisions so Kotlin language features do not accidentally conflict with Hibernate behavior.
Choose it only for a JPA / Hibernate model. Exposed's DSL, DAO, transaction, and migration choices belong to kotlin-exposed-patterns, so the persistence implementation decides which conditional workflow applies.
The final workflows solve different Kotlin boundaries. Coroutines and Flow, Kotlin/Native build diagnosis, and Apollo GraphQL operations should be selected from concrete repository evidence, not treated as interchangeable tooling.
kotlin-tooling-native-build-performance
437 installs KotlinConditional · Kotlin/Native
Best for: Kotlin/Native build diagnosis and performance investigation
kotlin-tooling-native-build-performance is a Kotlin/Native build diagnosis workflow. It focuses on isolating build-performance evidence and identifying the relevant build behavior before changing native configuration.
Use it conditionally when Kotlin/Native build performance is the actual problem. It is distinct from coroutine and Flow behavior, and from Apollo GraphQL client operations.
Kotlin/Native build-performance diagnosis
Evidence-led investigation of build behavior
Native configuration checks before tuning
A performance workflow, not an Apple package migration
671 installs Chris BanesCore specialty · Coroutines and Flow
Best for: Kotlin coroutine, Flow, StateFlow, SharedFlow, or channel behavior
kotlin-concurrency-and-flow is a focused workflow for Kotlin coroutine and reactive-state behavior. It identifies coroutine ownership and cancellation boundaries, then selects StateFlow, SharedFlow, Channel, stateIn, and sharing behavior from the actual producer and consumer contract.
Use it when concurrent Kotlin code or Flow state needs implementation or review. It addresses a common Kotlin and Android/KMP development boundary rather than a one-time packaging migration, while kotlin-patterns remains the broad language default.
Coroutine owner, lifetime, and cancellation boundaries
StateFlow, SharedFlow, and Channel selection
Flow sharing, buffering, replay, and event behavior
Structured concurrency and review of unstructured launches
1.4K installs Apollo GraphQLConditional · Apollo GraphQL
Best for: GraphQL client work in a Kotlin application using Apollo Kotlin
apollo-kotlin is the Apollo GraphQL client workflow for Kotlin. It covers GraphQL code generation, operations, and cache behavior so schema changes and client usage remain aligned with Apollo Kotlin's generated model.
Choose it conditionally when the application uses Apollo Kotlin. Apollo GraphQL is a product-specific client workflow, not an alternative to native build diagnosis or coroutine and Flow guidance.
Selection should follow the repository signal. Use the core language default for ordinary Kotlin work, the testing baseline when tests are central, and a narrow conditional workflow only for its named framework, toolchain, migration, or product.
1.Start with Kotlin language work. Use kotlin-patterns for idioms, structured concurrency, implementation, and refactoring. This is the broad language default, not a reason to load every backend or platform card.
2.Prove behavior with the testing baseline. Choose kotlin-testing when Kotest specifications, MockK collaborators, or Kover coverage are the deliverable. It is a broad Foundation testing choice, not a framework-specific replacement for the language workflow.
3.Match the backend and persistence model. Use Ktor for routing, plugins, and testApplication in a Ktor service. Use Spring Boot for a Spring Boot service. Within persistence, Exposed DSL / DAO transactions differ from JPA / Hibernate entity lifecycle, equality, and mapping, so select the conditional workflow that matches the existing model.
4.Route migrations, concurrency, and product boundaries narrowly. Use the Java-to-Kotlin audit for a conversion, Kotlin/Native for build-performance diagnosis, coroutines and Flow for ownership, cancellation, state, and event behavior, and Apollo GraphQL for codegen, operations, and cache behavior. These workflows solve different jobs and should not be combined by language association alone.
Ktor versus Spring Boot, Exposed versus JPA / Hibernate
Ktor and Spring Boot both host Kotlin backends, but they are not the same implementation context. Ktor work is about routing, plugins, and testApplication at a comparatively direct application boundary. Spring Boot work is about Kotlin-aware configuration and the conventions around a Spring service, including its JPA integration points. The build files and application setup decide which conditional card is relevant.
Exposed and JPA / Hibernate also represent different persistence models. Exposed changes should reason about DSL or DAO usage, transactions, and migrations. JPA / Hibernate changes should reason about entity lifecycle, equality, and mappings. Do not merge those workflows into one generic database recipe because both projects happen to use Kotlin.
Coroutines and Flow, native performance, and Apollo GraphQL
Coroutines and Flow need deliberate owner, cancellation, state, and event semantics. Kotlin/Native performance work instead starts with build diagnosis and evidence. Select each only when that concrete concurrency or native-build problem exists.
Apollo Kotlin is narrower still. It belongs to an application using Apollo GraphQL, where code generation, operations, and cache behavior determine whether the client matches the schema. It does not replace native build diagnosis or coroutine and Flow guidance, even when all three appear in a Kotlin Multiplatform repository.
Keep Kotlin skills visible with LazySkills
LazySkills scans installed skills, shows which agents can see them, diagnoses broken configurations, and searches the same skills.sh registry used for this guide. Install the catalog manager, then add the Kotlin workflow that matches the active repository boundary.
Use kotlin-patterns for an ordinary Kotlin implementation or refactor. It is the only language-level default. Use kotlin-testing as the broad testing baseline when behavior, Kotest, MockK, or Kover is the center of the task, then select a conditional workflow only when the repository proves that framework, toolchain, migration, or product boundary.
When should Kotlin testing replace the language workflow?
Use kotlin-testing when the deliverable is test behavior, mocks, or coverage evidence. It is a broad Foundation testing baseline, not a framework-specific choice and not the language default. Keep kotlin-patterns as the implementation baseline when tests are supporting a normal code change.
How should an agent choose Ktor versus Spring Boot?
Choose kotlin-ktor-patterns only for a Ktor repository, where routing, plugins, and testApplication are the relevant boundaries. Choose kotlin-springboot only for a Spring Boot repository, where Kotlin and JPA configuration shape the service. Kotlin alone does not decide between these conditional framework workflows.
How do Exposed and JPA / Hibernate differ in this guide?
Use kotlin-exposed-patterns for Exposed DSL or DAO work, transactions, and migrations. Use kotlin-backend-jpa-entity-mapping for JPA / Hibernate entity lifecycle, equality, and mapping decisions. They are different persistence models, so do not combine their instructions without repository evidence.
Which Kotlin tooling card fits concurrency, native, and GraphQL work?
Use kotlin-concurrency-and-flow for coroutine ownership, cancellation, and Flow state or events. Use kotlin-tooling-native-build-performance for Kotlin/Native build diagnosis and performance evidence. Use apollo-kotlin for Apollo GraphQL codegen, operations, and cache behavior. These workflows have different boundaries and should be selected from the repository's actual technology.
When is the Java-to-Kotlin card appropriate?
Use kotlin-tooling-java-to-kotlin only when Java source is being converted or the conversion needs an audit. It checks semantics, nullability, APIs, and generated changes after conversion. New Kotlin code without a Java migration should start with kotlin-patterns instead.
svgdiagram.ai 
