kotlin-project-modularization

Name: kotlin-project-modularization
Author: mmiani

56stars5forks

How to install kotlin-project-modularization?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-project-modularization

$npx -y skills add mmiani/kotlin-kmp-claude-agent-skills --skill kotlin-project-modularization

Installs into the current project.

Summary

Use when designing, reviewing, or refactoring module boundaries in KMP or Android projects — feature, data, app, and common modules, dependency direction, visibility control, and granularity.

Files · 1

View on GitHub

SKILL.md

1	# Kotlin Multiplatform Modularization
2
3	Use this skill when designing, reviewing, or refactoring module boundaries in a Kotlin Multiplatform project.
4
5	This skill is intentionally strict. Its purpose is to keep module boundaries meaningful, dependency direction clean, ownership clear, visibility tight, and project growth manageable.
6
7	## Primary goals
8
9	The modularization strategy should optimize for:
10
11	- reusability
12	- strict visibility control
13	- scalability
14	- ownership
15	- encapsulation
16	- testability
17	- build performance
18	- clear app entry points
19	- separation of platform-specific dependencies from reusable code
20
21	Do not modularize only for aesthetics.
22	Modularization should create clearer ownership and lower coupling.
23
24	---
25
26	## Official defaults to prefer
27
28	Unless the codebase has a strong reason not to, prefer:
29
30	- modules with a clear purpose
31	- narrow public APIs
32	- hidden implementation details
33	- feature ownership that is easy to infer
34	- shared code extracted only when it is truly shared
35	- module boundaries that reduce coupling
36	- app modules as entry points
37	- feature modules aligned to screens or closely related flows
38	- data modules that expose repositories and hide data sources
39	- common/core modules only for code reused by many modules
40	- Kotlin/Java modules instead of Android modules where Android resources, assets, and manifest support are unnecessary
41
42	---
43
44	## Benefits to review for
45
46	A modular design is stronger when it improves:
47
48	- Reusability: modules act as building blocks and can be reused across variants or apps
49	- Strict visibility control: internal details stay hidden outside the module
50	- Scalability: changes stay local instead of cascading widely
51	- Ownership: one team or person can clearly own a module
52	- Encapsulation: each module knows as little as possible about others
53	- Testability: logic can be tested in isolation
54	- Build time: Gradle can better leverage parallelism, caching, and incremental builds
55
56	If the proposed modularization does not improve at least some of these, be skeptical.
57
58	---
59
60	## Module types to recognize
61
62	### 1. Data modules
63
64	A data module usually contains:
65	- repositories
66	- data sources
67	- model classes
68
69	Its primary responsibilities are:
70	- encapsulate all data and business logic of a certain domain
71	- expose the repository as the external API
72	- hide implementation details and data sources from the outside
73
74	Review expectations:
75	- repositories are the public surface
76	- data sources stay internal to the module
77	- data ownership is domain-oriented, not endpoint-oriented
78	- callers do not depend directly on local/remote sources
79
80	Flag as a concern when:
81	- a data module exposes transport or persistence details publicly
82	- repositories are thin pass-through wrappers
83	- multiple unrelated domains are bundled together without a good reason
84
85	### 2. Feature modules
86
87	A feature module is an isolated part of app functionality, usually a screen or a closely related flow.
88
89	Review expectations:
90	- a feature corresponds to a user-visible capability
91	- a feature module likely contains UI plus a ViewModel/state-holder
92	- feature modules depend on data modules
93	- feature ownership is obvious from the module name and content
94
95	Flag as a concern when:
96	- one feature is scattered across many unrelated modules
97	- feature modules contain unrelated cross-cutting concerns
98	- features depend on each other too directly and too broadly
99
100	### 3. App modules
101
102	App modules are application entry points.
103
104	Review expectations:
105	- app modules depend on feature modules
106	- app modules usually provide root navigation
107	- if multiple device types are targeted, separate app modules may be appropriate to isolate platform-specific dependencies
108
109	Flag as a concern when:
110	- app modules own feature business logic that should live lower
111	- platform-specific concerns are not separated where they should be
112	- app modules become oversized containers for unrelated code
113
114	### 4. Common or core modules
115
116	Common/core modules contain code that many modules reuse and do not represent one specific app layer by themselves.
117
118	Examples may include:
119	- UI/design system
120	- analytics
121	- networking infrastructure
122
123	Review expectations:
124	- common modules exist because the code is genuinely reused
125	- they do not become dumping grounds
126	- their APIs stay focused and narrow
127
128	Flag as a concern when:
129	- `core`, `common`, or `shared` modules accumulate unrelated responsibilities
130	- code is moved into common modules too early
131	- common modules become backdoors that weaken feature boundaries
132
133	---
134
135	## Review dimensions
136
137	### 1. Module purpose clarity
138
139	Check whether every module has a clear purpose.
140
141	Questions:
142	- Can the module be described in one sentence?
143	- Is

People who liked this also viewed

6 picks

Type

kotlin-project-modularization

56stars5forks

View on GitHub

How to install kotlin-project-modularization?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-project-modularization

$npx -y skills add mmiani/kotlin-kmp-claude-agent-skills --skill kotlin-project-modularization

Installs into the current project.

Summary

Use when designing, reviewing, or refactoring module boundaries in KMP or Android projects — feature, data, app, and common modules, dependency direction, visibility control, and granularity.

Files · 1

View on GitHub

SKILL.md

1	# Kotlin Multiplatform Modularization
2
3	Use this skill when designing, reviewing, or refactoring module boundaries in a Kotlin Multiplatform project.
4
5	This skill is intentionally strict. Its purpose is to keep module boundaries meaningful, dependency direction clean, ownership clear, visibility tight, and project growth manageable.
6
7	## Primary goals
8
9	The modularization strategy should optimize for:
10
11	- reusability
12	- strict visibility control
13	- scalability
14	- ownership
15	- encapsulation
16	- testability
17	- build performance
18	- clear app entry points
19	- separation of platform-specific dependencies from reusable code
20
21	Do not modularize only for aesthetics.
22	Modularization should create clearer ownership and lower coupling.
23
24	---
25
26	## Official defaults to prefer
27
28	Unless the codebase has a strong reason not to, prefer:
29
30	- modules with a clear purpose
31	- narrow public APIs
32	- hidden implementation details
33	- feature ownership that is easy to infer
34	- shared code extracted only when it is truly shared
35	- module boundaries that reduce coupling
36	- app modules as entry points
37	- feature modules aligned to screens or closely related flows
38	- data modules that expose repositories and hide data sources
39	- common/core modules only for code reused by many modules
40	- Kotlin/Java modules instead of Android modules where Android resources, assets, and manifest support are unnecessary
41
42	---
43
44	## Benefits to review for
45
46	A modular design is stronger when it improves:
47
48	- Reusability: modules act as building blocks and can be reused across variants or apps
49	- Strict visibility control: internal details stay hidden outside the module
50	- Scalability: changes stay local instead of cascading widely
51	- Ownership: one team or person can clearly own a module
52	- Encapsulation: each module knows as little as possible about others
53	- Testability: logic can be tested in isolation
54	- Build time: Gradle can better leverage parallelism, caching, and incremental builds
55
56	If the proposed modularization does not improve at least some of these, be skeptical.
57
58	---
59
60	## Module types to recognize
61
62	### 1. Data modules
63
64	A data module usually contains:
65	- repositories
66	- data sources
67	- model classes
68
69	Its primary responsibilities are:
70	- encapsulate all data and business logic of a certain domain
71	- expose the repository as the external API
72	- hide implementation details and data sources from the outside
73
74	Review expectations:
75	- repositories are the public surface
76	- data sources stay internal to the module
77	- data ownership is domain-oriented, not endpoint-oriented
78	- callers do not depend directly on local/remote sources
79
80	Flag as a concern when:
81	- a data module exposes transport or persistence details publicly
82	- repositories are thin pass-through wrappers
83	- multiple unrelated domains are bundled together without a good reason
84
85	### 2. Feature modules
86
87	A feature module is an isolated part of app functionality, usually a screen or a closely related flow.
88
89	Review expectations:
90	- a feature corresponds to a user-visible capability
91	- a feature module likely contains UI plus a ViewModel/state-holder
92	- feature modules depend on data modules
93	- feature ownership is obvious from the module name and content
94
95	Flag as a concern when:
96	- one feature is scattered across many unrelated modules
97	- feature modules contain unrelated cross-cutting concerns
98	- features depend on each other too directly and too broadly
99
100	### 3. App modules
101
102	App modules are application entry points.
103
104	Review expectations:
105	- app modules depend on feature modules
106	- app modules usually provide root navigation
107	- if multiple device types are targeted, separate app modules may be appropriate to isolate platform-specific dependencies
108
109	Flag as a concern when:
110	- app modules own feature business logic that should live lower
111	- platform-specific concerns are not separated where they should be
112	- app modules become oversized containers for unrelated code
113
114	### 4. Common or core modules
115
116	Common/core modules contain code that many modules reuse and do not represent one specific app layer by themselves.
117
118	Examples may include:
119	- UI/design system
120	- analytics
121	- networking infrastructure
122
123	Review expectations:
124	- common modules exist because the code is genuinely reused
125	- they do not become dumping grounds
126	- their APIs stay focused and narrow
127
128	Flag as a concern when:
129	- `core`, `common`, or `shared` modules accumulate unrelated responsibilities
130	- code is moved into common modules too early
131	- common modules become backdoors that weaken feature boundaries
132
133	---
134
135	## Review dimensions
136
137	### 1. Module purpose clarity
138
139	Check whether every module has a clear purpose.
140
141	Questions:
142	- Can the module be described in one sentence?
143	- Is

People who liked this also viewed

6 picks

Type