메뉴
Use when designing, implementing, or reviewing Android deep links, web links, and App Links in KMP projects — intent-filter design, host verification, manifest scope, and assetlinks.json configuration.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.
Use when reviewing KMP architecture, feature proposals, PR structure, layer boundaries, state-holder design, Android entry-point discipline, source-set placement, modularization, and long-term maintainability in Kotlin Multiplatform / Compose Multiplatform projects.
Refactor discipline for existing codebases. Enforces scope control, migration safety, compatibility, observability, and tests to keep refactors reviewable and low-risk.
Use when diagnosing and fixing bugs in a Kotlin Multiplatform project. Focus on root-cause analysis, minimal safe fixes, KMP correctness, UI/state/data/persistence/concurrency issues, and regression prevention.
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 skill.
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.
| name | kotlin-platform-app-links-and-deep-links |
| description | Use when designing, implementing, or reviewing Android deep links, web links, and App Links in KMP projects — intent-filter design, host verification, manifest scope, and assetlinks.json configuration. |
| license | Apache-2.0 |
| metadata | {"author":"Mariano Miani","version":"1.1.0"} |
Use this skill when designing, implementing, or reviewing deep-linking behavior in a Kotlin Multiplatform project with Android support.
This skill is intentionally strict. Its purpose is to keep Android deep links, web links, and App Links structurally correct, verified where appropriate, compatible with realistic navigation behavior, and separated cleanly from shared route interpretation logic.
The deep-linking design should optimize for:
Do not treat all incoming URLs as equivalent. Treat verified App Links as a distinct architectural surface.
Unless the project has a strong reason not to, prefer:
VIEW, DEFAULT, and BROWSABLE<data> semanticsassetlinks.json when using Dynamic App Links on Android 15+Examples:
myapp://product/123Use when:
Risks:
Examples:
https://example.com/product/123These are standard web URLs. Without App Link verification, Android may still show disambiguation or route to the browser depending on app/user/system state.
These are verified HTTP(S) web links associated with your website. They provide the strongest user-trust and ownership model for opening app content from your web domains.
Review expectation:
Check whether the proposal uses the right link type for the job.
Prefer:
Flag as a concern when:
For Android deep links and App Links, review whether the manifest filters are structurally correct.
Expected pieces:
android.intent.action.VIEWandroid.intent.category.DEFAULTandroid.intent.category.BROWSABLECheck whether:
Important review rule:
<data> elements in one filter, because Android merges them and may create unintended URL combinationsFlag as a concern when:
Review whether host verification is designed correctly.
Check whether:
Important platform behavior:
Flag as a concern when:
Review whether static manifest rules are scoped well.
For Dynamic App Links, Google recommends:
assetlinks.jsonCheck whether:
Flag as a concern when:
Review website association files carefully.
Check whether:
/.well-known/assetlinks.jsonapplication/jsondelegate_permission/common.handle_all_urls where full App Link handling is intendedFlag as a concern when:
This is a platform-version-gated feature. Dynamic App Links are available only on Android 15+ (API 35+) and are not relevant for projects targeting lower minimum API levels. Treat this guidance as conditional on the project's min SDK target.
Dynamic App Links add server-side refinement on top of App Links.
Check whether:
Important review rule:
Flag as a concern when:
Keep Android registration and verification concerns platform-specific.
Prefer:
assetlinks.json ownership handled at the Android/platform layerFor non-Android KMP targets (web, desktop), deep-link handling is a different concern: Compose Multiplatform web targets can bind navigation state to browser URLs via the navigation library's web-target APIs. See the kotlin-navigation-compose-multiplatform skill for shared route and web-URL binding guidance. Android-specific App Link verification does not apply to those targets.
Flag as a concern when:
commonMainDeep links should take users directly to relevant content, and navigation after entry should still feel coherent.
Check whether:
Flag as a concern when:
Check whether deep links and App Links can be validated operationally.
Prefer:
Flag as a concern when:
Likely to cause broken ownership or broken user routing.
Examples:
<data> elementsassetlinks.jsonWorkable, but likely to create maintenance cost or inconsistent UX.
Examples:
Structurally acceptable but worth improving.
Examples:
When performing the review, respond with:
Deep-linking summary
What is structurally sound
Issues by review dimension
Severity for each issue
Concrete recommendations
Suggested target structure
Open risks
Be direct and practical. Do not assume “link opens app” means the setup is correct. If verification, scope, or routing is weak, say so clearly.
<data> declarations merged into one filter accidentallyassetlinks.json on one of several supported hosts/.well-known/assetlinks.json