kotlin-project-feature-implementation

Name: kotlin-project-feature-implementation
Author: mmiani

56stars5forks

How to install kotlin-project-feature-implementation?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-project-feature-implementation

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

Installs into the current project.

Summary

Use when implementing or extending a feature in a Kotlin Multiplatform project. Provides pre-coding inspection, KMP source-set discipline, state pipeline design, architectural defaults, security/performance guardrails, and implementation rules. Forward-looking only — not a review

Files · 1

View on GitHub

SKILL.md

1	# Kotlin Multiplatform Feature Implementation
2
3	Use this skill when implementing a new feature or extending an existing flow in a Kotlin Multiplatform project.
4
5	This skill is forward-looking only. It is not a review skill. It does not produce verdicts or issue severity ratings. For post-implementation or PR review, use `kotlin-project-architecture-review` instead.
6
7	Your job is to deliver production-grade code that fits the existing architecture, respects the shared UI system, preserves module boundaries, and remains easy to maintain over time.
8
9	Do not optimize for speed of output alone.
10	Optimize for correctness, scalability, maintainability, security, consistency, and clean evolution of the existing codebase.
11
12	---
13
14	## What this skill does
15
16	- Provides a pre-coding inspection checklist to read the codebase before writing anything
17	- States the architectural defaults to implement against
18	- Gives layer-by-layer implementation rules
19	- Defines KMP source-set placement discipline
20	- Defines state pipeline and data ownership expectations
21	- Enforces shared UI system usage
22	- Adds performance, coroutine, concurrency, and security guardrails
23	- Defines the expected output format for an implementation plan
24
25	---
26
27	## Primary goals
28
29	For every implementation, optimize for:
30
31	1. Architectural consistency
32	2. Small, coherent diffs
33	3. Business logic in the right layer
34	4. Strong separation of concerns
35	5. Model and boundary integrity
36	6. Predictable state management
37	7. Shared UI system consistency
38	8. Composable, reusable design
39	9. Compose performance
40	10. Coroutine and threading correctness
41	11. Concurrency and race-condition safety
42	12. Security and privacy safety
43	13. Source-of-truth discipline
44	14. Testability
45	15. Migration and rollout safety
46	16. Long-term maintainability
47
48	---
49
50	## Default architecture assumptions
51
52	Unless the project clearly does otherwise, implement features using:
53
54	- UI driven from immutable state
55	- user events flowing into a state holder
56	- repositories owning data access and coordination
57	- domain layer only when business logic is complex, reused, or meaningfully reduces state-holder complexity
58	- shared logic in `commonMain` only when valid for all declared targets
59	- platform code at the edges
60	- narrow module APIs and cohesive feature ownership
61	- tests alongside new logic, not deferred
62
63	Do not invent new structure if the codebase already has a valid one. Match conventions unless there is a clear reason not to, and state that reason explicitly in the implementation plan.
64
65	---
66
67	## Implementation philosophy
68
69	Before writing code, understand how the existing app already solves similar problems.
70
71	Do not introduce parallel patterns unless the current pattern is clearly broken and the task explicitly requires changing it.
72
73	Default behavior:
74	- preserve existing architecture
75	- extend existing modules rather than creating shadow flows
76	- reuse existing components before creating new ones
77	- make the smallest coherent implementation that solves the task correctly
78	- keep business logic out of UI
79	- avoid unrelated refactors
80	- prefer explicit, readable code over clever abstractions
81
82	---
83
84	## Step 0: Read before writing
85
86	Inspect the relevant existing feature before writing any code. Identify:
87
88	1. Module boundaries — which modules own the feature area, and what their public APIs are
89	2. Source-set placement — what is in `commonMain` vs platform source sets; where new code belongs
90	3. Route and navigation ownership — where routes are defined, how new screens integrate
91	4. State-holder pattern in use — ViewModel, presenter, state machine; what the existing contract looks like
92	5. Repository and data-source abstractions — existing interfaces, implementations, source-of-truth rules, error model
93	6. Domain layer presence and rationale — whether it exists, whether it adds value, whether new logic belongs there
94	7. Error-model conventions — exceptions, result wrappers, sealed error types; what the project uses consistently
95	8. Existing tests — test locations, test doubles, patterns already established
96	9. Shared UI system usage — existing shared components, spacing tokens, typography patterns, strings/localization patterns
97	10. Similar flows already implemented — find the closest existing feature and copy the pattern, not just the visual result
98
99	Do not start coding before grounding the implementation in the current codebase.
100
101	---
102
103	## Required workflow
104
105	Follow this workflow for every feature unless explicitly told otherwise.
106
107	###

mmianiPublisher · 15 listings

Preview

mmiani/kotlin-kmp-claude-agent-skills

# Kotlin Multiplatform Feature Implementation

Use this skill when **implementing** a new feature or extending an existing flow in a Kotlin Multiplatform project.

This skill is forward-looking only. It is not a review skill. It does not produce verdicts or issue severity ratings. For post-implementation or PR review, use

Your job is to deliver production-grade code that fits the existing architecture, respects the shared UI system, preserves module boundaries, and remains easy t

Repommiani/kotlin-kmp-claude-agent-skills

License—

TypeSkills

CategoryCoding

UpdatedApr 2026

Repo stars56

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

kotlin-project-feature-implementation

56stars5forks

View on GitHub

How to install kotlin-project-feature-implementation?

mmiani/kotlin-kmp-claude-agent-skills/kotlin-project-feature-implementation

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Kotlin Multiplatform Feature Implementation
2
3	Use this skill when implementing a new feature or extending an existing flow in a Kotlin Multiplatform project.
4
5	This skill is forward-looking only. It is not a review skill. It does not produce verdicts or issue severity ratings. For post-implementation or PR review, use `kotlin-project-architecture-review` instead.
6
7	Your job is to deliver production-grade code that fits the existing architecture, respects the shared UI system, preserves module boundaries, and remains easy to maintain over time.
8
9	Do not optimize for speed of output alone.
10	Optimize for correctness, scalability, maintainability, security, consistency, and clean evolution of the existing codebase.
11
12	---
13
14	## What this skill does
15
16	- Provides a pre-coding inspection checklist to read the codebase before writing anything
17	- States the architectural defaults to implement against
18	- Gives layer-by-layer implementation rules
19	- Defines KMP source-set placement discipline
20	- Defines state pipeline and data ownership expectations
21	- Enforces shared UI system usage
22	- Adds performance, coroutine, concurrency, and security guardrails
23	- Defines the expected output format for an implementation plan
24
25	---
26
27	## Primary goals
28
29	For every implementation, optimize for:
30
31	1. Architectural consistency
32	2. Small, coherent diffs
33	3. Business logic in the right layer
34	4. Strong separation of concerns
35	5. Model and boundary integrity
36	6. Predictable state management
37	7. Shared UI system consistency
38	8. Composable, reusable design
39	9. Compose performance
40	10. Coroutine and threading correctness
41	11. Concurrency and race-condition safety
42	12. Security and privacy safety
43	13. Source-of-truth discipline
44	14. Testability
45	15. Migration and rollout safety
46	16. Long-term maintainability
47
48	---
49
50	## Default architecture assumptions
51
52	Unless the project clearly does otherwise, implement features using:
53
54	- UI driven from immutable state
55	- user events flowing into a state holder
56	- repositories owning data access and coordination
57	- domain layer only when business logic is complex, reused, or meaningfully reduces state-holder complexity
58	- shared logic in `commonMain` only when valid for all declared targets
59	- platform code at the edges
60	- narrow module APIs and cohesive feature ownership
61	- tests alongside new logic, not deferred
62
63	Do not invent new structure if the codebase already has a valid one. Match conventions unless there is a clear reason not to, and state that reason explicitly in the implementation plan.
64
65	---
66
67	## Implementation philosophy
68
69	Before writing code, understand how the existing app already solves similar problems.
70
71	Do not introduce parallel patterns unless the current pattern is clearly broken and the task explicitly requires changing it.
72
73	Default behavior:
74	- preserve existing architecture
75	- extend existing modules rather than creating shadow flows
76	- reuse existing components before creating new ones
77	- make the smallest coherent implementation that solves the task correctly
78	- keep business logic out of UI
79	- avoid unrelated refactors
80	- prefer explicit, readable code over clever abstractions
81
82	---
83
84	## Step 0: Read before writing
85
86	Inspect the relevant existing feature before writing any code. Identify:
87
88	1. Module boundaries — which modules own the feature area, and what their public APIs are
89	2. Source-set placement — what is in `commonMain` vs platform source sets; where new code belongs
90	3. Route and navigation ownership — where routes are defined, how new screens integrate
91	4. State-holder pattern in use — ViewModel, presenter, state machine; what the existing contract looks like
92	5. Repository and data-source abstractions — existing interfaces, implementations, source-of-truth rules, error model
93	6. Domain layer presence and rationale — whether it exists, whether it adds value, whether new logic belongs there
94	7. Error-model conventions — exceptions, result wrappers, sealed error types; what the project uses consistently
95	8. Existing tests — test locations, test doubles, patterns already established
96	9. Shared UI system usage — existing shared components, spacing tokens, typography patterns, strings/localization patterns
97	10. Similar flows already implemented — find the closest existing feature and copy the pattern, not just the visual result
98
99	Do not start coding before grounding the implementation in the current codebase.
100
101	---
102
103	## Required workflow
104
105	Follow this workflow for every feature unless explicitly told otherwise.
106
107	###

mmianiPublisher · 15 listings

Preview

mmiani/kotlin-kmp-claude-agent-skills

# Kotlin Multiplatform Feature Implementation

Use this skill when **implementing** a new feature or extending an existing flow in a Kotlin Multiplatform project.

This skill is forward-looking only. It is not a review skill. It does not produce verdicts or issue severity ratings. For post-implementation or PR review, use

Your job is to deliver production-grade code that fits the existing architecture, respects the shared UI system, preserves module boundaries, and remains easy t

Repommiani/kotlin-kmp-claude-agent-skills

License—

TypeSkills

CategoryCoding

UpdatedApr 2026

Repo stars56

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type