run-local-verifications
Skill1.1k starsChanged 5 days agoApache-2.0View on GitHub
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.
We split this skill into the rules it gives an agent
17 rules. About 0 are common, 2 are distinctive, and 15 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
15
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 24
Use the running_gradle_builds skill for all Gradle build/generation tasks and the running_gradle_tests skill for all Gradle test tasks.
- Distinctive: line 31
Before running anything, determine which files were modified.
- Very specific: line 61
After running the verification checks above, run tests for the specific modules you changed using the running_gradle_tests skill.
- Very specific: line 71
All JVM tests for a module (preferred for commonMain changes): task <module>:jvmTest
- Very specific: line 77
Run checkLegacyAbi via running_gradle_builds -- if it fails, run updateLegacyAbi and commit
- Very specific: line 78
Run detekt via running_gradle_builds -- check output
- Very specific: line 79
Run :jpms-check:compileJava via running_gradle_builds
- Very specific: line 84
Use verify-compiler-plugin-compatibility skill for multi-version check
- Very specific: line 87
Run dumpPlatformTable --no-configuration-cache via running_gradle_builds then commit if changed
- Very specific: line 88
Run ./scripts/validate_published_artifacts.sh --dump -s via shell then commit if changed
- Very specific: line 97
Run ./scripts/update_implicit_types.sh via shell then commit if changed (if protoc-gen changed)
- Very specific: line 99
Run relevant module jvmTest via running_gradle_tests
- Very specific: line 110
Run kotlinUpgradeYarnLock and kotlinWasmUpgradeYarnLock via running_gradle_builds
- Very specific: line 111
Run checkLegacyAbi via running_gradle_builds -- API dumps may need updating
- Distinctive: line 116
Verify Writerside markup is valid (CI will build it, not runnable locally)
- Very specific: line 117
If you changed the changelog: run updateDocsChangelog via running_gradle_builds
- Very specific: line 122
Troubleshooting: read references/troubleshooting.md — consult when verifications fail unexpectedly
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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) | Protobuf unit tests | :tests:protobuf-unittest:test (use running_gradle_tests) | Validates protobuf codegen correctness |
protoc-gen/ sources (any change) | Well-Known Types | :protobuf:protobuf-wkt:bufGenerateCommonMain then check git status | Codegen changes may affect WKT generated code |
protoc-gen/ sources (any change) | Implicit imports | Shell: ./scripts/update_implicit_types.sh then check git status | Keeps protoc-gen implicit import list current |
protobuf/protobuf-wkt/ sources | Well-Known Types | :protobuf:protobuf-wkt:bufGenerateCommonMain then check git status | Regenerates WKT code |
krpc/ protocol wire format or serialization | Protocol compat tests | :tests:krpc-protocol-compatibility-tests:jvmTest (use running_gradle_tests) | Ensures wire format backward compatibility |
krpc/ any changes | kRPC compat tests | :tests:krpc-compatibility-tests:jvmTest (use running_gradle_tests) | Ensures old/new API compatibility |
| JS/WASM npm dependency changes or Kotlin version update | Yarn lock update | kotlinUpgradeYarnLock and/or kotlinWasmUpgradeYarnLock | Keeps JS/WASM lock files in sync |
tests/protobuf-conformance/**/known_failures.txt | Conformance known-failures | :tests:protobuf-conformance:jvmTest (see conformance details) | Removed entries must actually pass now; added entries must actually fail |
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
checkLegacyAbiviarunning_gradle_builds-- if it fails, runupdateLegacyAbiand commit - Run
detektviarunning_gradle_builds-- check output - Run
:jpms-check:compileJavaviarunning_gradle_builds - Run
:core:jvmTestviarunning_gradle_tests
"I modified the compiler plugin"
- Run
:tests:compiler-plugin-tests:testviarunning_gradle_tests - Use
verify-compiler-plugin-compatibilityskill for multi-version check
"I added a new published module"
- Run
dumpPlatformTable --no-configuration-cacheviarunning_gradle_buildsthen commit if changed - Run
./scripts/validate_published_artifacts.sh --dump -svia shell then commit if changed - Run
updatePropertiesviarunning_gradle_buildsthen commit if changed - Run
checkLegacyAbiviarunning_gradle_builds - Run
:jpms-check:compileJavaviarunning_gradle_builds
"I changed protobuf/gRPC code"
- Run
:protobuf:protobuf-wkt:bufGenerateCommonMainviarunning_gradle_buildsthen commit if changed - Run
tests:protobuf-conformance:bufGenerateCommonMainviarunning_gradle_buildsthen commit if changed - Run
:tests:protobuf-unittest:testviarunning_gradle_tests - Run
./scripts/update_implicit_types.shvia shell then commit if changed (if protoc-gen changed) - Run
checkLegacyAbiviarunning_gradle_builds - Run relevant module
jvmTestviarunning_gradle_tests
"I changed kRPC code"
- Run
:tests:krpc-protocol-compatibility-tests:jvmTestviarunning_gradle_tests - Run
:tests:krpc-compatibility-tests:jvmTestviarunning_gradle_tests - Run
checkLegacyAbiviarunning_gradle_builds - Run
detektviarunning_gradle_builds-- check output - Run relevant module
jvmTestviarunning_gradle_tests
"I updated the Kotlin version"
- Use
verify-compiler-plugin-compatibilityskill - Run
kotlinUpgradeYarnLockandkotlinWasmUpgradeYarnLockviarunning_gradle_builds - Run
checkLegacyAbiviarunning_gradle_builds-- API dumps may need updating - Run
:jpms-check:compileJavaviarunning_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
updateDocsChangelogviarunning_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
Trending
Quiet since September.about the whole repository
Who's talking about Kotlin/kotlinx-rpc
- bright-room/mindstock“fix(deps): update kotlinx.rpc to v0.10.4”GitHub · Sep 25, 2026
- bright-room/mindstock“fix(deps): update kotlinx.rpc to v0.10.3”GitHub · Jul 10, 2026
- modelix/modelix.editor“fix(deps): update kotlinx.rpc to v0.10.4”GitHub · Jul 6, 2026
- ktorio/ktor-plugin-registry“Bump the all-gradle group with 11 updates”GitHub · Jun 30, 2026
- DerTyp7214/synara-api“chore(deps): bump kotlinx-rpc from 0.10.2 to 0.10.3”GitHub · Jun 27, 2026
The biggest 5 of 16 mentions linking to the repository that our crawl found. Each line is their own headline.
See all 16
Talked about on GitHub (16 times).
On GitHub · 16
- Sep 25, 2026fix(deps): update kotlinx.rpc to v0.10.4 — bright-room/mindstock0 reactions · 1 comment
- Jul 10, 2026fix(deps): update kotlinx.rpc to v0.10.3 — bright-room/mindstock0 reactions
- Jul 6, 2026fix(deps): update kotlinx.rpc to v0.10.4 — modelix/modelix.editor0 reactions · 1 comment
- Jun 30, 2026Bump the all-gradle group with 11 updates — ktorio/ktor-plugin-registry0 reactions
- Jun 27, 2026chore(deps): bump kotlinx-rpc from 0.10.2 to 0.10.3 — DerTyp7214/synara-api0 reactions · 1 comment
11 more on GitHub
- May 3, 2026Add compiler plugin implementation and Kotlin External FIR Support — TBSten/cream0 reactions
- Mar 30, 2026build(deps): bump kotlinx-rpc from 0.10.1 to 0.10.2 — modelix/modelix.editor0 reactions · 5 comments
- Jan 17, 2026chore(deps): bump kotlinx-rpc from 0.10.1 to 0.10.2 — DerTyp7214/synara-api0 reactions · 2 comments
- Dec 20, 2025build(deps): bump org.jetbrains.kotlinx:kotlinx-rpc-krpc-ktor-client from 0.10.0 to 0.10.1 — DerTyp7214/synara-api0 reactions · 1 comment
- Dec 20, 2025build(deps): bump org.jetbrains.kotlinx:kotlinx-rpc-krpc-ktor-server from 0.10.0 to 0.10.1 — DerTyp7214/synara-api0 reactions · 1 comment
- Jul 3, 2025Update kxrpc tutorial to 0.8.0 — ktorio/ktor-documentation0 reactions · 2 comments
- Jul 3, 2025Update kxrpc to 0.8.0 — ktorio/ktor-plugin-registry0 reactions · 1 comment
- Apr 4, 2025Update kxrpc to 0.6.0 — ktorio/ktor-plugin-registry0 reactions · 1 comment
- Jan 28, 2025Update kxrpc to 0.5.0 — ktorio/ktor-plugin-registry0 reactions
- Jan 7, 2025Migrate cloud-run server to RPC ProtoBuf — ashdavies/playground.ashdavies.dev0 reactions
- May 26, 2024KotlinでRemote Procedure Calls (RPC) を簡単に行えるライブラリkotlinx.rpc — AndroidDagashi/AndroidDagashi0 reactions
In this repository19 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- commit-changesSkill
- file-youtrack-issueSkill
- fix-issueSkill
- gh-stackSkill
- gradle_expertSkill
- interacting_with_project_runtimeSkill
- introspecting_gradle_projectsSkill
- managing_gradle_dependenciesSkill
- researching_gradle_internalsSkill
- running_gradle_buildsSkill
- running_gradle_testsSkill
- searching_dependency_sourcesSkill
- update-docSkill
- update-shimSkill
- use-develocitySkill
- use-teamcitySkill
- use-youtrackSkill
- verify-compiler-plugin-compatibilitySkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.