| name | run-local-verifications |
| description | Determine which LOCAL verification checks to run for kotlinx-rpc changes and execute them on the developer's machine. TeamCity builds and GitHub Actions workflows are out of scope -- this skill covers only what can and should be run locally before pushing. Use this skill whenever changes are made to the codebase and you need to verify correctness before committing or opening a PR. Also use it when the user asks to "run checks", "verify changes", "run verifications", "what checks do I need", "validate my changes", "pre-PR checks", or "local checks". Trigger proactively after completing any code modification task -- even if the user doesn't explicitly ask, suggest which verifications are relevant based on what changed.
|
Run Local Verifications
Identify which verification checks are needed based on what changed, then run them
locally. This skill covers only checks that can be executed on the developer's machine.
TeamCity CI builds and GitHub Actions workflows are out of scope -- they run automatically
on push/PR and cannot be triggered from here.
How to Execute
Use the running_gradle_builds skill for all Gradle build/generation tasks and the
running_gradle_tests skill for all Gradle test tasks. Do NOT run ./gradlew directly
via shell. The only exception is ./scripts/update_implicit_types.sh and
./scripts/validate_published_artifacts.sh which are standalone shell scripts.
Quick Start: Identify What Changed
Before running anything, determine which files were modified. Use git diff or
git status to see the changed files, then match them against the decision table below.
Decision Table
Match changed paths to required verifications. Multiple rows can match -- run all that apply.
The "Gradle task" column shows the task name to pass to the appropriate Gradle skill.
| What changed | Verification | Gradle task / command | Why |
|---|
Any public API in published modules (core/, krpc/, grpc/, protobuf/, utils/) | ABI compatibility | checkLegacyAbi | Ensures binary compatibility is preserved for library consumers |
| Any Kotlin/Java source file | Detekt static analysis | detekt | Code quality. Does NOT fail the build, but check console output for new violations |
Any published JVM or KMP module source (including commonMain) | JPMS check | :jpms-check:compileJava | Verifies Java module system compatibility. commonMain code compiles to JVM too |
| New/removed modules or KMP target changes | Artifact validation | Shell: ./scripts/validate_published_artifacts.sh -s | Ensures the published artifact list stays consistent |
| New/removed modules or KMP target changes | Platform table | dumpPlatformTable --no-configuration-cache then check git status | Updates docs/pages platform table |
gradle.properties in any module | Properties sync | updateProperties then check git status | Keeps all module gradle.properties in sync with root |
compiler-plugin/ sources or templates | Compiler plugin tests | :tests:compiler-plugin-tests:test (use running_gradle_tests) | Validates codegen and diagnostics |
compiler-plugin/ CSM templates | Compiler version compat | Use the verify-compiler-plugin-compatibility skill | Ensures all supported Kotlin versions still compile |
protoc-gen/ sources (any change) | Protobuf conformance | tests:protobuf-conformance:bufGenerateCommonMain then check git status | Codegen changes may affect conformance test output |
protoc-gen/ sources (any change) |
Module-Specific Tests
After running the verification checks above, run tests for the specific modules you changed
using the running_gradle_tests skill.
Prefer jvmTest for KMP modules -- if your changes are in commonMain only, jvmTest
is the fastest way to validate them since common code compiles to all targets. Only run
jsTest, wasmJsTest, or nativeTest if the change is target-specific or you want full
coverage.
Examples:
- Single test: task
<module>:jvmTest --tests "TestClass.testMethod"
- All JVM tests for a module (preferred for commonMain changes): task
<module>:jvmTest
- Target-specific: task
<module>:jsTest, <module>:wasmJsTest, <module>:nativeTest
Common Scenarios
"I changed a public API in :core"
- Run
checkLegacyAbi via running_gradle_builds -- if it fails, run updateLegacyAbi and commit
- Run
detekt via running_gradle_builds -- check output
- Run
:jpms-check:compileJava via running_gradle_builds
- Run
:core:jvmTest via running_gradle_tests
"I modified the compiler plugin"
- Run
:tests:compiler-plugin-tests:test via running_gradle_tests
- Use
verify-compiler-plugin-compatibility skill for multi-version check
"I added a new published module"
- Run
dumpPlatformTable --no-configuration-cache via running_gradle_builds then commit if changed
- Run
./scripts/validate_published_artifacts.sh --dump -s via shell then commit if changed
- Run
updateProperties via running_gradle_builds then commit if changed
- Run
checkLegacyAbi via running_gradle_builds
- Run
:jpms-check:compileJava via running_gradle_builds
"I changed protobuf/gRPC code"
- Run
:protobuf:protobuf-wkt:bufGenerateCommonMain via running_gradle_builds then commit if changed
- Run
tests:protobuf-conformance:bufGenerateCommonMain via running_gradle_builds then commit if changed
- Run
:tests:protobuf-unittest:test via running_gradle_tests
- Run
./scripts/update_implicit_types.sh via shell then commit if changed (if protoc-gen changed)
- Run
checkLegacyAbi via running_gradle_builds
- Run relevant module
jvmTest via running_gradle_tests
"I changed kRPC code"
- Run
:tests:krpc-protocol-compatibility-tests:jvmTest via running_gradle_tests
- Run
:tests:krpc-compatibility-tests:jvmTest via running_gradle_tests
- Run
checkLegacyAbi via running_gradle_builds
- Run
detekt via running_gradle_builds -- check output
- Run relevant module
jvmTest via running_gradle_tests
"I updated the Kotlin version"
- Use
verify-compiler-plugin-compatibility skill
- Run
kotlinUpgradeYarnLock and kotlinWasmUpgradeYarnLock via running_gradle_builds
- Run
checkLegacyAbi via running_gradle_builds -- API dumps may need updating
- Run
:jpms-check:compileJava via running_gradle_builds
- Full test suite
"I only changed documentation"
- Verify Writerside markup is valid (CI will build it, not runnable locally)
- If you changed the changelog: run
updateDocsChangelog via running_gradle_builds
References
- Detailed verification guides (what each check does, failure recovery, edge cases): read
references/verification-details.md — consult when a check fails or behavior is unclear
- Troubleshooting: read
references/troubleshooting.md — consult when verifications fail unexpectedly