igorescodro 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
- Domain Layer — Domain model, repository interface, use case interface + impl → see
references/DOMAIN_LAYER.md - Data Layer — Repository mapper + RepositoryImpl → see
references/DATA_LAYER.md- If the feature needs a new database table, invoke the
write-local-datasourceskill first
- If the feature needs a new database table, invoke the
- Koin DI — Feature module, RepositoryModule, KoinHelper registration → see
references/KOIN_DI.md - Presentation — ViewModel, Composables, Navigation, strings → see delegation below
- 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-viewmodelskill - Composables + Screens → use
write-composableskill - Navigation → use
navigationskill - Strings → use
localizationskill - New Kuvio component needed → use
write-design-system-componentskill before implementing the composable
Phase 5: Tests
- Use case / ViewModel unit tests → use
write-unit-testsskill - UI / composable tests → use
write-ui-testsskill - End-to-end flow tests → use
write-e2e-testsskill
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 |