mcpField
K
kotlin-api-design

kotlin-api-design

github.com/chrisbanesDevelopment1.1k991 installsUpdated 1d ago
Repository

About kotlin-api-design

A Kotlin API design skill for developers choosing where behavior, types, and platform-specific details belong. It provides decision procedures for function ownership, value types, multiplatform boundaries, and control flow.

Key features

  1. 01Place domain concepts with clear owners
  2. 02Choose appropriate function ownership
  3. 03Check exhaustive sealed-result mappings
  4. 04Design semantically precise single-field types
  5. 05Isolate platform and native SDK details

Use cases

  1. 01Review ownership of extensions or factories
  2. 02Design a single-field domain type
  3. 03Separate shared code from platform implementations
  4. 04Check sealed-type branch completeness

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/chrisbanes/skills --skill kotlin-api-design

After installing, type/kotlin-api-designin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
functions.md
multiplatform-boundaries.md
value-classes.md

Details

From the project README

Kotlin API design

Core principle

Place behavior, types, and platform seams where their meaning is clearest to callers; use the smallest public abstraction that preserves domain language and platform independence.

Procedure

  1. Name the domain concept, its owning type or module, and the callers that need to depend on it.
  2. Choose function ownership before adding an extension, factory, helper, or service layer. When rejecting one, name the owner callers should use instead.
  3. When reviewing a public mapping over a sealed result, name every caller-visible outcome. Flag a catch-all else that hides a subtype and recommend explicit subtype branches so the contract stays exhaustive and preserves smart casts.
  4. Represent a single-field domain concept with the smallest type that preserves its semantic and interop contract.
  5. Keep shared code semantic; put native SDK and platform details behind an interface or a narrowly justified expect/actual boundary.
  6. Read the focused reference for the selected decision below.
  7. Finish when the public surface states domain intent, platform details remain at leaves, and callers do not depend on convenience abstractions with no clear owner.

Topic router

SignalRead
Member vs top-level, extension, factory, service, or receiver choiceFunction ownership
Primitive obsession, one-field domain type, @JvmInline value class, data class, interop, or Compose stabilityValue classes
Source sets, platform services, native SDKs, files, sensors, permissions, Compose Multiplatform interop, or expect/actualMultiplatform boundaries
Branching, guard-condition shape, sealed-result mapping, or a catch-all elseKotlin control flow

Comments

Markdown supported