Skip to main content

kotlin-gradle-build

Design, repair, and validate Kotlin Gradle builds using Kotlin DSL, version catalogs, Java toolchains, multi-module boundaries, dependency scopes, compiler options, reproducible CI, publishing, and cache-safe tasks. Use for settings.gradle.kts, build.gradle.kts, gradle.properties, wrapper, module layout, dependency, toolchain, or CI problems.

설치로 이동

소스 정보

저장소
full-stack-skills/kotlin-skills
최근 소스 활동
2026년 9월 11일 13:43
감지된 SKILL.md 언어
영어
스타
0
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
5 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
kotlin-gradle-build
license
Apache-2.0
description
Design, repair, and validate Kotlin Gradle builds using Kotlin DSL, version catalogs, Java toolchains, multi-module boundaries, dependency scopes, compiler options, reproducible CI, publishing, and cache-safe tasks. Use for settings.gradle.kts, build.gradle.kts, gradle.properties, wrapper, module layout, dependency, toolchain, or CI problems.
# Kotlin Gradle Build Own the build graph and reproducibility boundary; defer source semantics to `kotlin-stable` and behavioral test design to `kotlin-testing`. ## Inspect first - Read wrapper properties, settings, root and module builds, version catalogs, convention plugins, and CI workflows. - Record Kotlin Gradle plugin, Gradle, AGP if present, Java toolchain, JVM target, repositories, and dependency locking policy. - Run `gradle projects`, `gradle tasks`, and dependency insight only for the relevant configuration. - Verify versions against official compatibility documentation before upgrades. ## Build rules - Prefer the checked-in Gradle wrapper for projects; keep wrapper checksum validation enabled in CI. - Use Kotlin DSL and convention plugins for shared policy. Keep root builds declarative. - Declare Java toolchains and Kotlin compiler options explicitly; align `jvmTarget` with the selected runtime contract. - Centralize versions in a catalog or coherent platform, but do not obscure ownership of dependency scopes. - Use `api` only for types exposed by the public ABI; otherwise prefer `implementation`. - Make custom tasks lazy, cache-correct, and explicit about inputs, outputs, environment, and side effects. - Keep credentials in Gradle providers or CI secrets. Never write tokens into source, properties committed to Git, logs, or generated metadata. - Separate production modules from the dedicated `<project>-test` whole-project acceptance module used by migrations. ## Multi-module pattern ```text project/ ├── settings.gradle.kts ├── build-logic/ ├── core/ ├── adapters/ └── project-test/ # cross-module acceptance and source-parity suite ``` ## Verification ```bash ./gradlew --no-daemon projects ./gradlew --no-daemon check ./gradlew --no-daemon build ``` For publishing, add artifact inspection, reproducible metadata, signing, and a clean consumer-project test. Do not accept a build that works only from an IDE.
GitHub에서 보기