igorescodro/write-feature

Write Feature

Overview

A complete Alkaa feature spans five layers: domain models → repository interface → data implementation → Koin DI → presentation. Each layer has strict conventions. This skill guides you through all five in order.

Before starting: Use superpowers:brainstorming to align on scope and API design. Use superpowers:writing-plans if the feature is large.

Phases

1. Domain Layer — Domain model, repository interface, use case interface + impl → see references/DOMAIN_LAYER.md
2. Data Layer — Repository mapper + RepositoryImpl → see references/DATA_LAYER.md
   • If the feature needs a new database table, invoke the write-local-datasource skill first
3. Koin DI — Feature module, RepositoryModule, KoinHelper registration → see references/KOIN_DI.md
4. Presentation — ViewModel, Composables, Navigation, strings → see delegation below
5. Tests — Unit, UI, E2E → see delegation below

Rules

| Rule | Details | |------|---------| | Use cases are internal | internal visibility — never public | | One use case = one action | Never inject another ViewModel or feature module directly | | Flow vs. suspend | Flow<T> for streams; suspend fun for one-shot mutations. No Result<T> wrapping | | Mappers required | Never return the entity directly — local ↔ repo ↔ domain separation is required | | ViewModels inject use cases | Never inject repositories into ViewModels | | Register in KoinHelper immediately | Missing registration causes silent runtime crashes | | API module only when shared | Only create <name>-api when another feature depends on this one → see references/FEATURE_API_MODULE.md | | Interactors for cross-feature side effects | When a use case must trigger an action in another feature, define an Interactor interface in domain/interactor/ — never import the feature directly → see references/INTERACTOR.md |

Phase 4: Presentation

• ViewModel → use write-viewmodel skill
• Composables + Screens → use write-composable skill
• Navigation → use navigation skill
• Strings → use localization skill
• New Kuvio component needed → use write-design-system-component skill before implementing the composable

Phase 5: Tests

• Use case / ViewModel unit tests → use write-unit-tests skill
• UI / composable tests → use write-ui-tests skill
• End-to-end flow tests → use write-e2e-tests skill

Common Mistakes

| Mistake | Fix | |---------|-----| | suspend fun for a stream | Use Flow<T> for streams; suspend only for one-shot mutations | | Wrapping return values in Result<T> | Don't — exceptions propagate through Flow | | One use case doing two things | Create separate use cases | | Skipping the mapper | Local ↔ repo ↔ domain separation is required | | Injecting a repository into the ViewModel | ViewModels inject use cases only | | Feature depending directly on another feature | Create a <name>-api module | | Registering in KoinHelper after the feature works | Register immediately — silent runtime crashes | | Reusing the domain model as the view model | Keep them separate — UI concerns must not bleed into domain | | Importing a feature module directly into a use case | Define an Interactor interface in domain/interactor/ instead → see references/INTERACTOR.md |