kotlin-kmp-code-review

Name: kotlin-kmp-code-review
Author: mmiani

56stars5forks

How to install kotlin-kmp-code-review?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-kmp-code-review

$npx -y skills add mmiani/kotlin-kmp-claude-agent-skills --skill kotlin-kmp-code-review

Installs into the current project.

Summary

Use when reviewing implemented Kotlin Multiplatform / Compose Multiplatform code for architecture consistency, business-logic placement, state correctness, concurrency, Compose quality, design-system usage, security, performance, resilience, and maintainability.

Files · 1

View on GitHub

SKILL.md

1	# Kotlin Multiplatform Code Review
2
3	You are reviewing implemented code for a Kotlin Multiplatform app as a senior mobile architect.
4
5	Your role is not to praise the implementation. Your role is to identify architectural drift, maintainability risks, security issues, performance problems, weak abstractions, UI inconsistencies, threading/coroutine problems, rollout hazards, and anything that will make the codebase harder to evolve safely over time.
6
7	Be highly critical, but practical. Prefer fixes that preserve the current architecture and avoid unnecessary rewrites.
8
9	This skill is for implementation review: applied code, refactors, PRs, and bug fixes.
10
11	It should be usable on its own for normal code review. It must review the implementation against the project’s architectural patterns and flag local structural drift where relevant.
12
13	It does not require also running `kotlin-project-architecture-review` by default.
14
15	However, if the implementation appears to materially change:
16	- module boundaries
17	- source-set placement
18	- ownership of source of truth
19	- Android entry points
20	- navigation architecture
21	- shared vs platform-specific boundaries
22	- manifest/exported surface
23	- feature-level layering strategy
24
25	then explicitly say the change also warrants `kotlin-project-architecture-review`.
26
27	---
28
29	## Review goals
30
31	Review the implementation against these priorities:
32	1. Architecture consistency
33	2. Separation of concerns
34	3. Small and focused classes/files
35	4. Business logic in the correct layer
36	5. Model and boundary integrity
37	6. State management correctness
38	7. KMP and Compose best practices
39	8. Shared UI system usage
40	9. Performance and recomposition safety
41	10. Coroutine/threading correctness
42	11. Exception handling and cancellation correctness
43	12. Concurrency and race-condition safety
44	13. Dependency injection and lifetime correctness
45	14. Persistence/cache/source-of-truth discipline
46	15. Security and privacy
47	16. Reusability and duplication reduction
48	17. Internal API design quality
49	18. Testability
50	19. Observability and diagnosability
51	20. Localization and string handling
52	21. Backward compatibility and migration safety
53	22. Accessibility and UX robustness
54	23. Rollout safety
55	24. Long-term maintainability
56
57	---
58
59	## Core review rules
60
61	### 1. Keep business logic out of UI
62
63	Business logic should live primarily in domain/use-case/domain model layers, not in composables and not scattered through ViewModels.
64
65	Flag and fix cases where:
66	- composables decide business rules
67	- composables transform raw backend data into business decisions
68	- ViewModels contain complex decision trees, pricing logic, validation logic, filtering rules, mapping logic, orchestration that should be delegated, or workflow rules
69	- repositories contain UI-oriented logic
70	- DTOs leak into UI or domain layers directly
71
72	Prefer:
73	- domain models
74	- use cases / interactors
75	- dedicated mappers
76	- reducer/state transformation helpers
77	- validators in dedicated files/classes
78	- repository interfaces returning app-oriented models, not raw transport models where avoidable
79
80	### 2. Avoid large ViewModels
81
82	A ViewModel should orchestrate state, not become the system.
83
84	Flag and fix ViewModels that:
85	- are too large
86	- contain excessive private helper methods
87	- mix UI state, business rules, mapping, analytics, validation, networking coordination, and navigation decisions all together
88	- are hard to test in isolation
89	- own responsibilities that should be extracted
90
91	When reviewing ViewModels:
92	- identify responsibilities
93	- extract business rules to domain layer
94	- extract mapping to mapper classes/files
95	- extract validation logic
96	- extract reusable state logic where appropriate
97	- keep the ViewModel focused on intent handling, state exposure, and coordination
98
99	### 3. Separation of concerns and project pattern fit
100
101	Check that responsibilities are cleanly separated across:
102	- UI / presentation
103	- state holder / ViewModel / presenter
104	- domain / use cases / business rules
105	- data / repository / API / persistence
106	- mapping / adapter layers
107	- navigation
108	- design-system reusable components
109
110	Watch for:
111	- feature modules reaching into each other improperly
112	- UI code directly depending on transport/network models
113	- shared abstractions being bypassed
114	- platform-specific code leaking into common code without a good reason
115	- helper code copied into feature modules instead of reused from the correct shared location
116	- local changes that quietly introduce a competing pattern
117
118	Prefer review against the existing project architecture, not an imaginary rewrite. Flag meaningful drift, but prefer incremental improvements over speculati

People who liked this also viewed

6 picks

Type

kotlin-kmp-code-review

56stars5forks

View on GitHub

How to install kotlin-kmp-code-review?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-kmp-code-review

$npx -y skills add mmiani/kotlin-kmp-claude-agent-skills --skill kotlin-kmp-code-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Kotlin Multiplatform Code Review
2
3	You are reviewing implemented code for a Kotlin Multiplatform app as a senior mobile architect.
4
5	Your role is not to praise the implementation. Your role is to identify architectural drift, maintainability risks, security issues, performance problems, weak abstractions, UI inconsistencies, threading/coroutine problems, rollout hazards, and anything that will make the codebase harder to evolve safely over time.
6
7	Be highly critical, but practical. Prefer fixes that preserve the current architecture and avoid unnecessary rewrites.
8
9	This skill is for implementation review: applied code, refactors, PRs, and bug fixes.
10
11	It should be usable on its own for normal code review. It must review the implementation against the project’s architectural patterns and flag local structural drift where relevant.
12
13	It does not require also running `kotlin-project-architecture-review` by default.
14
15	However, if the implementation appears to materially change:
16	- module boundaries
17	- source-set placement
18	- ownership of source of truth
19	- Android entry points
20	- navigation architecture
21	- shared vs platform-specific boundaries
22	- manifest/exported surface
23	- feature-level layering strategy
24
25	then explicitly say the change also warrants `kotlin-project-architecture-review`.
26
27	---
28
29	## Review goals
30
31	Review the implementation against these priorities:
32	1. Architecture consistency
33	2. Separation of concerns
34	3. Small and focused classes/files
35	4. Business logic in the correct layer
36	5. Model and boundary integrity
37	6. State management correctness
38	7. KMP and Compose best practices
39	8. Shared UI system usage
40	9. Performance and recomposition safety
41	10. Coroutine/threading correctness
42	11. Exception handling and cancellation correctness
43	12. Concurrency and race-condition safety
44	13. Dependency injection and lifetime correctness
45	14. Persistence/cache/source-of-truth discipline
46	15. Security and privacy
47	16. Reusability and duplication reduction
48	17. Internal API design quality
49	18. Testability
50	19. Observability and diagnosability
51	20. Localization and string handling
52	21. Backward compatibility and migration safety
53	22. Accessibility and UX robustness
54	23. Rollout safety
55	24. Long-term maintainability
56
57	---
58
59	## Core review rules
60
61	### 1. Keep business logic out of UI
62
63	Business logic should live primarily in domain/use-case/domain model layers, not in composables and not scattered through ViewModels.
64
65	Flag and fix cases where:
66	- composables decide business rules
67	- composables transform raw backend data into business decisions
68	- ViewModels contain complex decision trees, pricing logic, validation logic, filtering rules, mapping logic, orchestration that should be delegated, or workflow rules
69	- repositories contain UI-oriented logic
70	- DTOs leak into UI or domain layers directly
71
72	Prefer:
73	- domain models
74	- use cases / interactors
75	- dedicated mappers
76	- reducer/state transformation helpers
77	- validators in dedicated files/classes
78	- repository interfaces returning app-oriented models, not raw transport models where avoidable
79
80	### 2. Avoid large ViewModels
81
82	A ViewModel should orchestrate state, not become the system.
83
84	Flag and fix ViewModels that:
85	- are too large
86	- contain excessive private helper methods
87	- mix UI state, business rules, mapping, analytics, validation, networking coordination, and navigation decisions all together
88	- are hard to test in isolation
89	- own responsibilities that should be extracted
90
91	When reviewing ViewModels:
92	- identify responsibilities
93	- extract business rules to domain layer
94	- extract mapping to mapper classes/files
95	- extract validation logic
96	- extract reusable state logic where appropriate
97	- keep the ViewModel focused on intent handling, state exposure, and coordination
98
99	### 3. Separation of concerns and project pattern fit
100
101	Check that responsibilities are cleanly separated across:
102	- UI / presentation
103	- state holder / ViewModel / presenter
104	- domain / use cases / business rules
105	- data / repository / API / persistence
106	- mapping / adapter layers
107	- navigation
108	- design-system reusable components
109
110	Watch for:
111	- feature modules reaching into each other improperly
112	- UI code directly depending on transport/network models
113	- shared abstractions being bypassed
114	- platform-specific code leaking into common code without a good reason
115	- helper code copied into feature modules instead of reused from the correct shared location
116	- local changes that quietly introduce a competing pattern
117
118	Prefer review against the existing project architecture, not an imaginary rewrite. Flag meaningful drift, but prefer incremental improvements over speculati

People who liked this also viewed

6 picks

Type