Source profileQuality 80/100

affaan-m/ECC/skills/android-clean-architecture/SKILL.md

android-clean-architecture

Clean Architecture patterns for Android and Kotlin Multiplatform projects — module structure, dependency rules, UseCases, Repositories, and data layer patterns.

Source repository stars
234,327
Declared platforms
0
Static risk flags
1
Last source update
2026-07-27
Source checked
2026-07-28

Decision brief

What it does—and where it fits

Clean Architecture patterns for Android and KMP projects. Covers module boundaries, dependency inversion, UseCase/Repository patterns, and data layer design with Room, SQLDelight, and Ktor.

Best for

    Not for

    • Importing Android framework classes in domain — keep it pure Kotlin
    • Exposing database entities or DTOs to the UI layer — always map to domain models

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/affaan-m/ECC --skill "skills/android-clean-architecture"
    Safe inspection promptEditorial

    Inspect the Agent Skill "android-clean-architecture" from https://github.com/affaan-m/ECC/blob/4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38/skills/android-clean-architecture/SKILL.md at commit 4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      Repository Implementation

      Coordinates between local and remote data sources:

      Coordinates between local and remote data sources:
    2. 02

      When to Activate

      Structuring Android or KMP project modules

      Structuring Android or KMP project modulesImplementing UseCases, Repositories, or DataSourcesDesigning data flow between layers (domain, data, presentation)
    3. 03

      Module Structure

      Critical: domain must NEVER depend on data, presentation, or any framework. It contains pure Kotlin only.

      Critical: domain must NEVER depend on data, presentation, or any framework. It contains pure Kotlin only.
    4. 04

      Recommended Layout

      Review the “Recommended Layout” section in the pinned source before continuing.

      Review and apply the “Recommended Layout” source section.
    5. 05

      Dependency Rules

      Critical: domain must NEVER depend on data, presentation, or any framework. It contains pure Kotlin only.

      Critical: domain must NEVER depend on data, presentation, or any framework. It contains pure Kotlin only.

    Permission review

    Static risk signals and limitations

    Network access

    medium · line 222

    The documentation includes network, browsing, or remote request actions.

    defaultRequest { url("https://api.example.com/") }

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score80/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars234,327SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    affaan-m/ECC
    Skill path
    skills/android-clean-architecture/SKILL.md
    Commit
    4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38
    License
    MIT
    Collected
    2026-07-28
    Default branch
    main
    View the original SKILL.md

    Android Clean Architecture

    Clean Architecture patterns for Android and KMP projects. Covers module boundaries, dependency inversion, UseCase/Repository patterns, and data layer design with Room, SQLDelight, and Ktor.

    When to Activate

    • Structuring Android or KMP project modules
    • Implementing UseCases, Repositories, or DataSources
    • Designing data flow between layers (domain, data, presentation)
    • Setting up dependency injection with Koin or Hilt
    • Working with Room, SQLDelight, or Ktor in a layered architecture

    Module Structure

    Recommended Layout

    project/
    ├── app/                  # Android entry point, DI wiring, Application class
    ├── core/                 # Shared utilities, base classes, error types
    ├── domain/               # UseCases, domain models, repository interfaces (pure Kotlin)
    ├── data/                 # Repository implementations, DataSources, DB, network
    ├── presentation/         # Screens, ViewModels, UI models, navigation
    ├── design-system/        # Reusable Compose components, theme, typography
    └── feature/              # Feature modules (optional, for larger projects)
        ├── auth/
        ├── settings/
        └── profile/
    

    Dependency Rules

    app → presentation, domain, data, core
    presentation → domain, design-system, core
    data → domain, core
    domain → core (or no dependencies)
    core → (nothing)
    

    Critical: domain must NEVER depend on data, presentation, or any framework. It contains pure Kotlin only.

    Domain Layer

    UseCase Pattern

    Each UseCase represents one business operation. Use operator fun invoke for clean call sites:

    class GetItemsByCategoryUseCase(
        private val repository: ItemRepository
    ) {
        suspend operator fun invoke(category: String): Result<List<Item>> {
            return repository.getItemsByCategory(category)
        }
    }
    
    // Flow-based UseCase for reactive streams
    class ObserveUserProgressUseCase(
        private val repository: UserRepository
    ) {
        operator fun invoke(userId: String): Flow<UserProgress> {
            return repository.observeProgress(userId)
        }
    }
    

    Domain Models

    Domain models are plain Kotlin data classes — no framework annotations:

    data class Item(
        val id: String,
        val title: String,
        val description: String,
        val tags: List<String>,
        val status: Status,
        val category: String
    )
    
    enum class Status { DRAFT, ACTIVE, ARCHIVED }
    

    Repository Interfaces

    Defined in domain, implemented in data:

    interface ItemRepository {
        suspend fun getItemsByCategory(category: String): Result<List<Item>>
        suspend fun saveItem(item: Item): Result<Unit>
        fun observeItems(): Flow<List<Item>>
    }
    

    Data Layer

    Repository Implementation

    Coordinates between local and remote data sources:

    class ItemRepositoryImpl(
        private val localDataSource: ItemLocalDataSource,
        private val remoteDataSource: ItemRemoteDataSource
    ) : ItemRepository {
    
        override suspend fun getItemsByCategory(category: String): Result<List<Item>> {
            return runCatching {
                val remote = remoteDataSource.fetchItems(category)
                localDataSource.insertItems(remote.map { it.toEntity() })
                localDataSource.getItemsByCategory(category).map { it.toDomain() }
            }
        }
    
        override suspend fun saveItem(item: Item): Result<Unit> {
            return runCatching {
                localDataSource.insertItems(listOf(item.toEntity()))
            }
        }
    
        override fun observeItems(): Flow<List<Item>> {
            return localDataSource.observeAll().map { entities ->
                entities.map { it.toDomain() }
            }
        }
    }
    

    Mapper Pattern

    Keep mappers as extension functions near the data models:

    // In data layer
    fun ItemEntity.toDomain() = Item(
        id = id,
        title = title,
        description = description,
        tags = tags.split("|"),
        status = Status.valueOf(status),
        category = category
    )
    
    fun ItemDto.toEntity() = ItemEntity(
        id = id,
        title = title,
        description = description,
        tags = tags.joinToString("|"),
        status = status,
        category = category
    )
    

    Room Database (Android)

    @Entity(tableName = "items")
    data class ItemEntity(
        @PrimaryKey val id: String,
        val title: String,
        val description: String,
        val tags: String,
        val status: String,
        val category: String
    )
    
    @Dao
    interface ItemDao {
        @Query("SELECT * FROM items WHERE category = :category")
        suspend fun getByCategory(category: String): List<ItemEntity>
    
        @Upsert
        suspend fun upsert(items: List<ItemEntity>)
    
        @Query("SELECT * FROM items")
        fun observeAll(): Flow<List<ItemEntity>>
    }
    

    SQLDelight (KMP)

    -- Item.sq
    CREATE TABLE ItemEntity (
        id TEXT NOT NULL PRIMARY KEY,
        title TEXT NOT NULL,
        description TEXT NOT NULL,
        tags TEXT NOT NULL,
        status TEXT NOT NULL,
        category TEXT NOT NULL
    );
    
    getByCategory:
    SELECT * FROM ItemEntity WHERE category = ?;
    
    upsert:
    INSERT OR REPLACE INTO ItemEntity (id, title, description, tags, status, category)
    VALUES (?, ?, ?, ?, ?, ?);
    
    observeAll:
    SELECT * FROM ItemEntity;
    

    Ktor Network Client (KMP)

    class ItemRemoteDataSource(private val client: HttpClient) {
    
        suspend fun fetchItems(category: String): List<ItemDto> {
            return client.get("api/items") {
                parameter("category", category)
            }.body()
        }
    }
    
    // HttpClient setup with content negotiation
    val httpClient = HttpClient {
        install(ContentNegotiation) { json(Json { ignoreUnknownKeys = true }) }
        install(Logging) { level = LogLevel.HEADERS }
        defaultRequest { url("https://api.example.com/") }
    }
    

    Dependency Injection

    Koin (KMP-friendly)

    // Domain module
    val domainModule = module {
        factory { GetItemsByCategoryUseCase(get()) }
        factory { ObserveUserProgressUseCase(get()) }
    }
    
    // Data module
    val dataModule = module {
        single<ItemRepository> { ItemRepositoryImpl(get(), get()) }
        single { ItemLocalDataSource(get()) }
        single { ItemRemoteDataSource(get()) }
    }
    
    // Presentation module
    val presentationModule = module {
        viewModelOf(::ItemListViewModel)
        viewModelOf(::DashboardViewModel)
    }
    

    Hilt (Android-only)

    @Module
    @InstallIn(SingletonComponent::class)
    abstract class RepositoryModule {
        @Binds
        abstract fun bindItemRepository(impl: ItemRepositoryImpl): ItemRepository
    }
    
    @HiltViewModel
    class ItemListViewModel @Inject constructor(
        private val getItems: GetItemsByCategoryUseCase
    ) : ViewModel()
    

    Error Handling

    Result/Try Pattern

    Use Result<T> or a custom sealed type for error propagation:

    sealed interface Try<out T> {
        data class Success<T>(val value: T) : Try<T>
        data class Failure(val error: AppError) : Try<Nothing>
    }
    
    sealed interface AppError {
        data class Network(val message: String) : AppError
        data class Database(val message: String) : AppError
        data object Unauthorized : AppError
    }
    
    // In ViewModel — map to UI state
    viewModelScope.launch {
        when (val result = getItems(category)) {
            is Try.Success -> _state.update { it.copy(items = result.value, isLoading = false) }
            is Try.Failure -> _state.update { it.copy(error = result.error.toMessage(), isLoading = false) }
        }
    }
    

    Convention Plugins (Gradle)

    For KMP projects, use convention plugins to reduce build file duplication:

    // build-logic/src/main/kotlin/kmp-library.gradle.kts
    plugins {
        id("org.jetbrains.kotlin.multiplatform")
    }
    
    kotlin {
        androidTarget()
        iosX64(); iosArm64(); iosSimulatorArm64()
        sourceSets {
            commonMain.dependencies { /* shared deps */ }
            commonTest.dependencies { implementation(kotlin("test")) }
        }
    }
    

    Apply in modules:

    // domain/build.gradle.kts
    plugins { id("kmp-library") }
    

    Anti-Patterns to Avoid

    • Importing Android framework classes in domain — keep it pure Kotlin
    • Exposing database entities or DTOs to the UI layer — always map to domain models
    • Putting business logic in ViewModels — extract to UseCases
    • Using GlobalScope or unstructured coroutines — use viewModelScope or structured concurrency
    • Fat repository implementations — split into focused DataSources
    • Circular module dependencies — if A depends on B, B must not depend on A

    References

    See skill: compose-multiplatform-patterns for UI patterns. See skill: kotlin-coroutines-flows for async patterns.

    Alternatives

    Compare before choosing