kotlin-build-kmp-gradle-governance

Name: kotlin-build-kmp-gradle-governance
Author: mmiani

56stars5forks

How to install kotlin-build-kmp-gradle-governance?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-build-kmp-gradle-governance

$npx -y skills add mmiani/kotlin-kmp-claude-agent-skills --skill kotlin-build-kmp-gradle-governance

Installs into the current project.

Summary

Use when reviewing or designing Gradle build structure for KMP projects — shared build logic, convention plugins, version catalogs, Android KMP plugin usage, source-set configuration, and module dependency hygiene.

Files · 1

View on GitHub

SKILL.md

1	# Kotlin Multiplatform Gradle Governance
2
3	Use this skill when reviewing or designing Gradle build structure for a Kotlin Multiplatform project.
4
5	This skill is intentionally limited to guidance that is grounded in official Android, Gradle, and Kotlin Multiplatform documentation. It should avoid embedding stack-specific assumptions such as a particular DI framework, persistence library, obfuscation configuration, CI provider, or fixed plugin/version matrix unless the user explicitly asks for those.
6
7	## Primary goals
8
9	The review or design should optimize for:
10
11	- shared build logic instead of repeated module configuration
12	- clear, stable module boundaries
13	- source-set-correct KMP configuration
14	- dependency consistency across modules
15	- minimal public module surfaces
16	- maintainable plugin and dependency management
17
18	## Official defaults to prefer
19
20	Unless the project has a strong reason not to, prefer:
21
22	- convention plugins to share repeated build logic across modules
23	- version catalogs for centralized dependency and plugin coordinates
24	- explicit source-set-aware KMP configuration
25	- narrow module APIs and `implementation` by default instead of exposing transitive dependencies unnecessarily
26	- Android KMP library modules configured with the officially supported Android KMP library plugin when that plugin matches the project’s needs
27
28	---
29
30	## Review dimensions
31
32	### 1. Shared build logic
33
34	Check whether repeated Gradle configuration is centralized instead of duplicated.
35
36	Prefer:
37	- convention plugins or equivalent shared build logic
38	- one place to define repeated module defaults
39	- module build files that stay focused on what is unique to that module
40
41	Two common approaches for organizing convention plugins:
42	- `build-logic/` as an included build: a standalone Gradle build included via `includeBuild("build-logic")` in `settings.gradle`. This approach gives better IDE support, better build caching, and clearer isolation. It is the pattern used in the Android Now in Android reference project and is generally preferred for new projects.
43	- `buildSrc/`: a special Gradle directory that is automatically included before the main build. It is simpler to set up but offers weaker caching, slightly worse IDE performance on large projects, and is harder to migrate away from.
44
45	Either approach can work well. The key is that one of them is used rather than scattering convention logic across module scripts.
46
47	Flag as a concern when:
48	- many modules copy the same Android, Kotlin, or publishing configuration
49	- plugin and compiler settings drift across modules
50	- build logic is scattered across unrelated module scripts
51	- neither `buildSrc` nor an included build is used in a project large enough to benefit from shared build logic
52
53	### 2. Convention plugins
54
55	Review whether convention plugins are used appropriately.
56
57	Build-logic location: Convention plugins can live in `buildSrc/` (treated as an implicit included build) or an explicitly included build directory (commonly `build-logic/`). An explicit included build is generally preferred in modular projects because it supports better caching, cleaner IDE support, and clearer isolation. `buildSrc/` rebuilds on every sync even when unchanged, which can slow multi-module projects. If the project uses `buildSrc/`, consider flagging this for future migration if build performance is a concern.
58
59	Check whether:
60	- conventions are grouped around real module roles (e.g., `android-library`, `kmp-library`, `app`)
61	- the plugin logic configures existing plugins cleanly without unnecessary indirection
62	- conventions reduce duplication without hiding important module differences
63	- convention plugins enforce standards rather than introducing opaque magic
64	- the build-logic location is consistent and clearly understood by contributors
65
66	Flag as a concern when:
67	- convention plugins become dumping grounds for unrelated logic
68	- modules still require large repeated setup despite having convention plugins
69	- convention plugins bake in stack-specific choices (DI setup, obfuscation config) that should stay opt-in
70	- `buildSrc/` causes noticeable sync slowdowns in a large project that could benefit from an explicit included build
71
72	### 3. Version catalogs
73
74	Check whether dependency and plugin coordinates are centralized through version catalogs.
75
76	Prefer:
77	- consistent aliases for shared dependencies
78	- central version management
79	- reduced string-literal dependency declarations across modules
80
81	Flag as a concern when:
82	- versions are repeated in many module build files
83	- plugin and library coordinates drift across the build
84	- catalog usage is inconsistent enough that it no longer pro

People who liked this also viewed

6 picks

Type

kotlin-build-kmp-gradle-governance

56stars5forks

View on GitHub

How to install kotlin-build-kmp-gradle-governance?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-build-kmp-gradle-governance

$npx -y skills add mmiani/kotlin-kmp-claude-agent-skills --skill kotlin-build-kmp-gradle-governance

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Kotlin Multiplatform Gradle Governance
2
3	Use this skill when reviewing or designing Gradle build structure for a Kotlin Multiplatform project.
4
5	This skill is intentionally limited to guidance that is grounded in official Android, Gradle, and Kotlin Multiplatform documentation. It should avoid embedding stack-specific assumptions such as a particular DI framework, persistence library, obfuscation configuration, CI provider, or fixed plugin/version matrix unless the user explicitly asks for those.
6
7	## Primary goals
8
9	The review or design should optimize for:
10
11	- shared build logic instead of repeated module configuration
12	- clear, stable module boundaries
13	- source-set-correct KMP configuration
14	- dependency consistency across modules
15	- minimal public module surfaces
16	- maintainable plugin and dependency management
17
18	## Official defaults to prefer
19
20	Unless the project has a strong reason not to, prefer:
21
22	- convention plugins to share repeated build logic across modules
23	- version catalogs for centralized dependency and plugin coordinates
24	- explicit source-set-aware KMP configuration
25	- narrow module APIs and `implementation` by default instead of exposing transitive dependencies unnecessarily
26	- Android KMP library modules configured with the officially supported Android KMP library plugin when that plugin matches the project’s needs
27
28	---
29
30	## Review dimensions
31
32	### 1. Shared build logic
33
34	Check whether repeated Gradle configuration is centralized instead of duplicated.
35
36	Prefer:
37	- convention plugins or equivalent shared build logic
38	- one place to define repeated module defaults
39	- module build files that stay focused on what is unique to that module
40
41	Two common approaches for organizing convention plugins:
42	- `build-logic/` as an included build: a standalone Gradle build included via `includeBuild("build-logic")` in `settings.gradle`. This approach gives better IDE support, better build caching, and clearer isolation. It is the pattern used in the Android Now in Android reference project and is generally preferred for new projects.
43	- `buildSrc/`: a special Gradle directory that is automatically included before the main build. It is simpler to set up but offers weaker caching, slightly worse IDE performance on large projects, and is harder to migrate away from.
44
45	Either approach can work well. The key is that one of them is used rather than scattering convention logic across module scripts.
46
47	Flag as a concern when:
48	- many modules copy the same Android, Kotlin, or publishing configuration
49	- plugin and compiler settings drift across modules
50	- build logic is scattered across unrelated module scripts
51	- neither `buildSrc` nor an included build is used in a project large enough to benefit from shared build logic
52
53	### 2. Convention plugins
54
55	Review whether convention plugins are used appropriately.
56
57	Build-logic location: Convention plugins can live in `buildSrc/` (treated as an implicit included build) or an explicitly included build directory (commonly `build-logic/`). An explicit included build is generally preferred in modular projects because it supports better caching, cleaner IDE support, and clearer isolation. `buildSrc/` rebuilds on every sync even when unchanged, which can slow multi-module projects. If the project uses `buildSrc/`, consider flagging this for future migration if build performance is a concern.
58
59	Check whether:
60	- conventions are grouped around real module roles (e.g., `android-library`, `kmp-library`, `app`)
61	- the plugin logic configures existing plugins cleanly without unnecessary indirection
62	- conventions reduce duplication without hiding important module differences
63	- convention plugins enforce standards rather than introducing opaque magic
64	- the build-logic location is consistent and clearly understood by contributors
65
66	Flag as a concern when:
67	- convention plugins become dumping grounds for unrelated logic
68	- modules still require large repeated setup despite having convention plugins
69	- convention plugins bake in stack-specific choices (DI setup, obfuscation config) that should stay opt-in
70	- `buildSrc/` causes noticeable sync slowdowns in a large project that could benefit from an explicit included build
71
72	### 3. Version catalogs
73
74	Check whether dependency and plugin coordinates are centralized through version catalogs.
75
76	Prefer:
77	- consistent aliases for shared dependencies
78	- central version management
79	- reduced string-literal dependency declarations across modules
80
81	Flag as a concern when:
82	- versions are repeated in many module build files
83	- plugin and library coordinates drift across the build
84	- catalog usage is inconsistent enough that it no longer pro

People who liked this also viewed

6 picks

Type