| name | build-engineer |
| description | Chords build and release-engineering policy. Use for root and codegen/plugins Gradle build logic, buildSrc dependency coordinates, publishing wiring, version increments, generated `pom.xml`/`dependencies.md` reports, and the config submodule relationship.
|
Build Engineering
When to Use
Use this skill for build, dependency, and release-plumbing work:
- Root
build.gradle.kts, settings.gradle.kts, version.gradle.kts, and
gradle.properties.
buildSrc/ dependency coordinates, repository helpers, and convention
plugins (jvm-module, publishing, reports).- The
codegen/plugins Gradle project's own build logic and its
codegen-workspace resource packaging.
- Publishing configuration:
spinePublishing, artifact prefix, destination
repositories, and the publishCodegenPlugins* tasks.
- Version policy and the generated
pom.xml / dependencies.md reports.
- Detekt configuration under
quality/.
For workflow YAML under .github/workflows, use
.agents/skills/ci-engineer/SKILL.md.
Policy
- Two toolchains coexist: the root project uses JDK 11 / Gradle 6.9.4 /
Kotlin 1.8.20;
codegen/plugins uses JDK 17 / Gradle 9.4.x / Kotlin 2.3.20.
Keep build logic compatible with the owning toolchain.
- Dependency coordinates belong in
buildSrc/src/main/kotlin/io/spine/internal/dependency/, one object per
library, following the existing pattern. Do not inline version strings into
module build files.
- Do not auto-update external dependencies or toolchain versions outside
dedicated upgrade tasks; the pins match the Spine 1.9.x consumer ecosystem.
- Every PR increments
chordsVersion in version.gradle.kts
(2.0.0-SNAPSHOT.<N>); CI enforces this with checkVersionIncrement.
pom.xml and dependencies.md are generated by the build (PomGenerator and
LicenseReporter); regenerate them via ./gradlew build rather than editing,
and include the regenerated files in version-bump changesets.- The
config/ submodule is owned by SpineEventEngine/config; do not edit
its contents here. If shared build logic must change, describe the upstream
change instead.
- Do not run
publish or publishCodegenPlugins against remote repositories;
publishing is CI-owned (pushes to master). Local verification uses
publishToMavenLocal.
- Preserve the codegen wiring contract:
modulesWithChordsCodegen lists the
modules that get the io.spine.chords Gradle plugin, and
createCodegenWorkspace depends on publishCodegenPluginsToMavenLocal.
- Keep the Gradle plugin version (
io.spine.chords in build.gradle.kts and
Spine.kt in buildSrc) consistent in both places when bumping it.
Verification
Root build (repository root, JDK 11):
./gradlew clean build
./gradlew publishToMavenLocal
./gradlew checkVersionIncrement
Codegen plugins build (from codegen/plugins/, JDK 17):
./gradlew build
./gradlew publishToMavenLocal
Run the publishToMavenLocal variant when plugin publication is part of the
change, so root modules consume the rebuilt plugins.
After version or dependency changes, confirm pom.xml and dependencies.md
were regenerated and reflect the new version.
