菜单
Add a mapper that converts a remote DTO into a data-layer model. Use when asked to "map a dto", "add a mapper", "convert <X>Dto to a model", or whenever a data source's DTO needs turning into the data layer's own model type.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Add a screen's composables to a feature module using the Route → Screen → Content structure. Use when asked to "add a screen", "build the <X> screen", "wire up a screen's UI", or to render a feature's state. Pairs with add-viewmodel.
Add a ViewModel to a feature module using the Action / State / Event triad, depending on use case / repository interfaces. Use when asked to "add a viewmodel" or to wire a screen's state, actions, and events. The screen's composables are a separate skill (add-screen).
Add a reusable design-system Composable to the :ui module — stateless, themed via RickAndMortyTheme tokens, with a preview. Use when asked to "add a button", "add a shared component", "add a card/loader/empty state", or to build any reusable UI primitive shared across screens.
Unit-test a use case with hand-written fake repositories. Use when asked to "test a use case", "add use case tests", or to verify a use case's aggregation and error-propagation logic.
Unit-test a ViewModel's Action → State → Event behaviour with fakes. Use when asked to "test a viewmodel", "add viewmodel tests", or to verify a screen's state transitions and one-time events.
Add a repository to :data:core as composable single-unit repositories ([Verb][Name]Repository) encapsulated by a parent contract, each mapping a data source's RemoteResult into DataResult. Use when asked to "add a repository", "wire up a repository", or to expose data-layer operations to domain/presentation.
| name | add-dto-mapper |
| description | Add a mapper that converts a remote DTO into a data-layer model. Use when asked to "map a dto", "add a mapper", "convert <X>Dto to a model", or whenever a data source's DTO needs turning into the data layer's own model type. |
The mapper is the boundary that decouples the data layer's models from the wire format. Past the mapper, nothing knows about DTOs — so a JSON/field change on a DTO ripples no further than its mapper. Scope this skill to one concept's mapper.
| Thing | Module | Package | Notes |
|---|---|---|---|
| DTO (wire format) | :datasources:remote | ...remote.dto | @Serializable, mirrors the JSON |
| Data model | :data:core | ...data.model | plain data class, no serialization annotations |
| Mapper | :data:core | ...data.mappers | internal extension fun Dto.toData() |
:data:core depends on :datasources:remote, so the mapper can see the DTO; the DTO
never depends on the model (the dependency points one way, inward).
In :datasources:remote, ...remote.dto — see the add-remote-datasource
skill:
@Serializable
data class CharacterDto(val id: Int, val name: String)
:data:core, ...data.model/Character.kt — the data layer's own type, free of any
wire concerns:
data class Character(val id: Int, val name: String)
:data:core, ...data.mappers/CharacterMapper.kt — one extension function per
concept. Always name it toData() — every DTO → model mapper follows this
one convention, so the call site reads the same everywhere (dto.toData()):
internal fun CharacterDto.toData() = Character(
id = id,
name = name,
)
Keep mapping logic total and pure: provide defaults for nullable/absent DTO fields here rather than leaking nullability into the model.
In the repository, feed the mapper into toDataResult (see add-repository):
remoteDatasource.getCharacter(id).toDataResult { it.toData() }
./gradlew :data:core:compileDebugSources --console=plain
(Set JAVA_HOME to a JDK 21 — e.g. an SDKMAN *-jbr — if the shell can't find
Java.)
...remote.dto and @Serializable.data class in ...data.model.internal extension fun named toData() in ...data.mappers,
one per concept.:data:core:compileDebugSources succeeds.