What problem does it solve? Choosing and wiring a transport layer between a Kotlin Multiplatform client and its Kotlin backend is error-prone: teams often duplicate HTTP calls alongside existing RPC services, misplace shared contracts, or pick REST when a typed Kotlin-to-Kotlin boundary would be simpler. This Skill provides decision guidance, module layout rules, and a scaffold script for kotlinx-rpc based architectures. ## Core Features & Use Cases - RPC vs REST vs gRPC decision guidance: Determines when Kotlin RPC fits (Kotlin-to-Kotlin boundaries) and when REST or gRPC is the better choice for public or cross-language APIs. - Shared contract architecture: Defines a clean split between shared service interfaces and DTOs, server-side Ktor wiring, and thin client stubs, with auth kept at the Ktor route boundary. - Streaming support: Documents kotlinx-rpc Flow streaming constraints (Flow only, non-suspending top-level return type) and the native gRPC/Protobuf option. - Scaffold script: Generates a starter shared/server/client RPC module layout with a single command. - Use Case: You are adding a data-layer call to a KMP app and need to know whether to extend an existing RPC service interface or create a new HTTP endpoint — the pre-implementation grep check and anti-pattern list prevent parallel transports from diverging. ## Quick Start Ask the agent to scaffold a Kotlin RPC layout for package com.example.app and design a GreetingService contract with shared request and response models.
