tajsos-kmp-architecture

Resolve code placement between commonMain and platform-specific layers in Kotlin Multiplatform projects.

3|Updated Mar 18, 2026
One-click install
npx skills add https://github.com/tajemniktv/TajsOS --skill tajsos-kmp-architecture
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tajsos-kmp-architecture
Source: https://github.com/tajemniktv/TajsOS/tree/main/.agent/skills/tajsos-kmp-architecture
Command: npx skills add https://github.com/tajemniktv/TajsOS --skill tajsos-kmp-architecture

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill resolves inconsistent and error-prone code placement decisions in TajsOS's Kotlin Multiplatform project, preventing shared code leaks into platform-specific layers and avoiding the misapplication of platform-only patterns to shared code.

Core Features & Use Cases

  • Shared-first boundary guidance: Clear rules for placing domain models, UI logic, and state management in commonMain when practical.
  • Android skill usage constraints: Prevents incorrectly applying Android-only architectural patterns to shared KMP or desktop code.
  • Platform abstraction rules: Provides guardrails for using expect/actual only when platform boundaries are stable and necessary.
  • Use Case: When adding a new task management feature to TajsOS, use this Skill to decide whether the core task logic belongs in commonMain or requires platform-specific implementations for Android and desktop.

Quick Start

Use the tajsos-kmp-architecture skill to determine the correct module placement for new code you are adding to the TajsOS KMP project.

Frequently Asked Questions about tajsos-kmp-architecture

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide where to place domain models and UI logic in Kotlin Multiplatform?

Apply a shared-first boundary approach by placing domain models, UI logic, and state management in commonMain by default. Only move code to platform-specific layers when true platform boundaries require distinct implementations.

When should I use expect/actual for platform abstraction in KMP projects?

Use expect/actual declarations for platform abstraction only when platform boundaries are stable and strictly necessary. Avoid using them prematurely for domain logic or UI state that could remain in commonMain.

How do I prevent Android-only architectural patterns from leaking into shared KMP code?

Prevent Android-only pattern leaks by enforcing shared-first boundaries that restrict platform-specific dependencies. Validate that architectural patterns applied to commonMain do not rely on Android-exclusive APIs or desktop-incompatible components.

Can I apply Android development skills directly to shared commonMain code?

No, Android development skills often introduce platform-specific dependencies. Apply architectural constraints to ensure Android-only patterns are not misapplied to shared commonMain or desktop targets in a Kotlin Multiplatform project.

What is the best way to manage state across Android and desktop targets in Kotlin Multiplatform?

Manage state across Android and desktop targets by keeping state management logic in commonMain. This shared-first boundary approach ensures both platforms utilize the same canonical implementation without platform-specific leaks.

Why does my shared KMP code fail when using platform-specific dependencies?

Shared KMP code fails because commonMain cannot directly resolve platform-specific dependencies. You must isolate platform APIs using expect/actual declarations or move the dependent logic to the respective Android or desktop source sets.