kotlin-data-kmp-data-layer

Name: kotlin-data-kmp-data-layer
Author: mmiani

56stars5forks

How to install kotlin-data-kmp-data-layer?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-data-kmp-data-layer

$npx -y skills add mmiani/kotlin-kmp-claude-agent-skills --skill kotlin-data-kmp-data-layer

Installs into the current project.

Summary

Use when implementing or reviewing KMP data layers, including repositories, data sources, source-of-truth design, API exposure, conflict resolution, error handling, and main-safe data operations.

Files · 1

View on GitHub

SKILL.md

1	# Kotlin Multiplatform Data Layer
2
3	Use this skill when designing, implementing, or reviewing the data layer in a Kotlin Multiplatform project.
4
5	This skill is intentionally strict. Its purpose is to keep repositories meaningful, data ownership explicit, source-of-truth decisions clear, and upper layers insulated from transport and persistence details.
6
7	## Primary goals
8
9	The data-layer design should optimize for:
10
11	- clear ownership of application data
12	- a single source of truth per repository
13	- repositories as the entry points to data access
14	- clean separation between repositories and data sources
15	- conflict resolution across multiple sources in one place
16	- API shapes that fit Kotlin best practices
17	- immutable exposed data
18	- main-safe repository and data-source APIs
19	- predictable failure handling
20	- testable mapping and coordination logic
21
22	---
23
24	## Official defaults to prefer
25
26	Unless the project has a strong reason not to, prefer these defaults:
27
28	- the data layer contains application data and business logic
29	- repositories expose data to the rest of the app
30	- repositories centralize changes to data
31	- repositories resolve conflicts between multiple data sources
32	- repositories abstract data sources from the rest of the app
33	- repositories act as the entry points to the data layer
34	- each data source is responsible for one source only
35	- each repository defines a single source of truth
36	- one-shot operations use `suspend` functions
37	- updates over time use `Flow`
38	- exposed data is immutable
39	- repository and data-source APIs are main-safe
40
41	---
42
43	## Review and implementation dimensions
44
45	### 1. Data-layer responsibility
46
47	The data layer is not only a transport layer.
48
49	Check whether:
50	- the data layer owns application data concerns
51	- business logic that belongs with data ownership is located here
52	- upper layers are protected from storage and transport details
53
54	Flag as a concern when:
55	- the data layer is treated as only an HTTP wrapper
56	- business rules around creation, storage, reconciliation, or change tracking leak upward
57	- repositories are too thin to add meaningful ownership or coordination
58
59	### 2. Repository responsibility
60
61	Repositories should be meaningful architectural boundaries.
62
63	Check whether each repository is responsible for:
64	- exposing data to the rest of the app
65	- centralizing changes to that data
66	- resolving conflicts between multiple sources
67	- abstracting data sources from callers
68	- containing business logic related to data ownership and coordination
69
70	Flag as a concern when:
71	- repositories merely mirror endpoint methods
72	- repositories expose transport-layer details directly
73	- upper layers coordinate local and remote sources themselves
74	- conflict resolution is duplicated outside the repository
75
76	### 3. Data-source responsibility
77
78	Each data source should work with exactly one source of data.
79
80	Examples:
81	- a network source
82	- a database source
83	- a file source
84	- an in-memory source
85
86	Check whether:
87	- each data source has a narrow responsibility
88	- repositories depend on data sources
89	- other layers do not depend on data sources directly
90
91	Flag as a concern when:
92	- ViewModels, presenters, use cases, or UI call data sources directly
93	- one data source mixes several unrelated storage/transport concerns
94	- repositories do not meaningfully sit between callers and sources
95
96	### 4. Source of truth
97
98	Each repository should define a single source of truth.
99
100	Check whether:
101	- the source of truth is explicit
102	- the data exposed from the repository comes from that source of truth
103	- the repository updates that source of truth consistently
104	- multi-source reconciliation feeds back into the source of truth
105
106	Strong candidates:
107	- local database
108	- in-memory cache for specific bounded cases
109
110	For offline-first behavior, prefer a local data source such as a database as the source of truth.
111
112	Flag as a concern when:
113	- multiple sources are treated as simultaneously authoritative
114	- UI consumes remote responses directly while local state is supposed to be canonical
115	- the source-of-truth choice is implicit or unstable
116
117	### 5. API shape
118
119	The data layer should expose APIs based on the kind of operation.
120
121	Prefer:
122	- `suspend` functions for one-shot CRUD-style operations
123	- `Flow` for observing changes over time
124
125	Check whether:
126	- one-shot work is modeled as one-shot APIs
127	- long-lived observation uses `Flow`
128	- callers receive stable APIs that match how the data behaves
129
130	Flag as a concern when:
131	- streaming data is exposed as repeated polling by upper layers without reason
132	- one-shot operations are modeled as long-lived observable streams unnecessarily
133	- API style is inconsistent across similar repositories
134
135	### 6. Immutability of exposed data
136
137	Th

People who liked this also viewed

6 picks

Type

kotlin-data-kmp-data-layer

56stars5forks

View on GitHub

How to install kotlin-data-kmp-data-layer?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-data-kmp-data-layer

$npx -y skills add mmiani/kotlin-kmp-claude-agent-skills --skill kotlin-data-kmp-data-layer

Installs into the current project.

Summary

Use when implementing or reviewing KMP data layers, including repositories, data sources, source-of-truth design, API exposure, conflict resolution, error handling, and main-safe data operations.

Files · 1

View on GitHub

SKILL.md

1	# Kotlin Multiplatform Data Layer
2
3	Use this skill when designing, implementing, or reviewing the data layer in a Kotlin Multiplatform project.
4
5	This skill is intentionally strict. Its purpose is to keep repositories meaningful, data ownership explicit, source-of-truth decisions clear, and upper layers insulated from transport and persistence details.
6
7	## Primary goals
8
9	The data-layer design should optimize for:
10
11	- clear ownership of application data
12	- a single source of truth per repository
13	- repositories as the entry points to data access
14	- clean separation between repositories and data sources
15	- conflict resolution across multiple sources in one place
16	- API shapes that fit Kotlin best practices
17	- immutable exposed data
18	- main-safe repository and data-source APIs
19	- predictable failure handling
20	- testable mapping and coordination logic
21
22	---
23
24	## Official defaults to prefer
25
26	Unless the project has a strong reason not to, prefer these defaults:
27
28	- the data layer contains application data and business logic
29	- repositories expose data to the rest of the app
30	- repositories centralize changes to data
31	- repositories resolve conflicts between multiple data sources
32	- repositories abstract data sources from the rest of the app
33	- repositories act as the entry points to the data layer
34	- each data source is responsible for one source only
35	- each repository defines a single source of truth
36	- one-shot operations use `suspend` functions
37	- updates over time use `Flow`
38	- exposed data is immutable
39	- repository and data-source APIs are main-safe
40
41	---
42
43	## Review and implementation dimensions
44
45	### 1. Data-layer responsibility
46
47	The data layer is not only a transport layer.
48
49	Check whether:
50	- the data layer owns application data concerns
51	- business logic that belongs with data ownership is located here
52	- upper layers are protected from storage and transport details
53
54	Flag as a concern when:
55	- the data layer is treated as only an HTTP wrapper
56	- business rules around creation, storage, reconciliation, or change tracking leak upward
57	- repositories are too thin to add meaningful ownership or coordination
58
59	### 2. Repository responsibility
60
61	Repositories should be meaningful architectural boundaries.
62
63	Check whether each repository is responsible for:
64	- exposing data to the rest of the app
65	- centralizing changes to that data
66	- resolving conflicts between multiple sources
67	- abstracting data sources from callers
68	- containing business logic related to data ownership and coordination
69
70	Flag as a concern when:
71	- repositories merely mirror endpoint methods
72	- repositories expose transport-layer details directly
73	- upper layers coordinate local and remote sources themselves
74	- conflict resolution is duplicated outside the repository
75
76	### 3. Data-source responsibility
77
78	Each data source should work with exactly one source of data.
79
80	Examples:
81	- a network source
82	- a database source
83	- a file source
84	- an in-memory source
85
86	Check whether:
87	- each data source has a narrow responsibility
88	- repositories depend on data sources
89	- other layers do not depend on data sources directly
90
91	Flag as a concern when:
92	- ViewModels, presenters, use cases, or UI call data sources directly
93	- one data source mixes several unrelated storage/transport concerns
94	- repositories do not meaningfully sit between callers and sources
95
96	### 4. Source of truth
97
98	Each repository should define a single source of truth.
99
100	Check whether:
101	- the source of truth is explicit
102	- the data exposed from the repository comes from that source of truth
103	- the repository updates that source of truth consistently
104	- multi-source reconciliation feeds back into the source of truth
105
106	Strong candidates:
107	- local database
108	- in-memory cache for specific bounded cases
109
110	For offline-first behavior, prefer a local data source such as a database as the source of truth.
111
112	Flag as a concern when:
113	- multiple sources are treated as simultaneously authoritative
114	- UI consumes remote responses directly while local state is supposed to be canonical
115	- the source-of-truth choice is implicit or unstable
116
117	### 5. API shape
118
119	The data layer should expose APIs based on the kind of operation.
120
121	Prefer:
122	- `suspend` functions for one-shot CRUD-style operations
123	- `Flow` for observing changes over time
124
125	Check whether:
126	- one-shot work is modeled as one-shot APIs
127	- long-lived observation uses `Flow`
128	- callers receive stable APIs that match how the data behaves
129
130	Flag as a concern when:
131	- streaming data is exposed as repeated polling by upper layers without reason
132	- one-shot operations are modeled as long-lived observable streams unnecessarily
133	- API style is inconsistent across similar repositories
134
135	### 6. Immutability of exposed data
136
137	Th

People who liked this also viewed

6 picks

Type