mcpbeat Sign in

Run Local Verifications Agent Skill

> 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.

5k tokens
context cost
the whole folder, loaded on every use
3
files
instructions only
0
copies elsewhere
how many repositories repackaged it
1063
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/Kotlin/kotlinx-rpc --skill run-local-verifications

What comes with it

10 477 bytes besides the instruction
references/troubleshooting.md
references/verification-details.md

The instruction itself

14 sections, as written by the author

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 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

Other skills for the same job

different authors, same section of the catalogue
MCP Builder
by anthropics
vendor ×13

Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).

30k tokens scripts
Changelog Generator
by frostant
×9

Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.

774 tokens
Finishing A Development Branch
by ZhanlinCui
×7

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

1k tokens
MCP Builder
by JayZeeDesign
×7

Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).

37k tokens scripts
Vercel React Native Skills
by vercel-labs
vendor ×6

React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.

39k tokens
Vercel React Best Practices
by ratacat
×5

React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.

34k tokens
Next Best Practices
by vercel-labs
vendor ×4

Next.js best practices - file conventions, RSC boundaries, data patterns, async APIs, metadata, error handling, route handlers, image/font optimization, bundling

20k tokens
Using Git Worktrees
by ZhanlinCui
×4

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

1k tokens

How to use it

Copy the folder

Take kotlin/run-local-verifications from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.