// Guides commit message writing for the kotlinx-rpc project. Use this skill whenever committing code, writing commit messages, or when the user asks about commit conventions. Also use it when reviewing PRs for commit message quality. Triggers on: /commit, "commit", "commit message", "git commit", writing changelogs from commits.
Autonomously fix a YouTrack issue end-to-end: from ticket pickup through code fix, tests, PR creation, CI validation, and reviewer assignment.
Modify, build, publish, and verify the Kotlin/Native shim artifacts (gRPC shim and protobuf shim) in native-deps/shims/. Use this skill whenever the user wants to change shim C/C++ source code, update shim headers or .def files, bump a shim upstream version, add or remove archives from the overlap excludes list, patch KLIB metadata, update the annotation module, run shim fixture tests, publish shim artifacts locally, or debug any native shim build failure. Also trigger when the user mentions "shim", "cinterop", "native interop", "grpc shim", "protobuf shim", "KLIB patcher", "overlap archives", "native-deps", "Bazel shim build", or "shim verification".
Query and analyze kotlinx-rpc build scans, test results, and failure patterns from the Develocity server (ge.jetbrains.com) using MCP tools. Use this skill whenever the user wants to look at build scans, investigate CI failures across builds, check build cache hit rates, analyze flaky tests, find recurring failure patterns, or query build performance history. Also trigger when the user mentions "Develocity", "build scan", "GE", "ge.jetbrains.com", "build cache stats", "flaky tests", "failure groups", or asks about build trends, test stability, or CI health. Trigger even if the user doesn't say "Develocity" explicitly -- if they want to look at historical build data, cross-build test analysis, or failure aggregation, this is the right skill. Do NOT use this skill for running local Gradle builds -- use `running_gradle_builds` or `running_gradle_tests` instead. Do NOT use this skill for TeamCity build triggering or queue management -- use `use-teamcity`.
File YouTrack issues for the kotlinx-rpc project (KRPC). Use this skill whenever the user wants to create a bug report, feature request, task, or any issue in YouTrack for kotlinx-rpc. Also use it when the user mentions filing a ticket, reporting a bug, creating a task, logging an issue, or tracking work in YouTrack — even if they don't say "YouTrack" explicitly but the context is clearly about issue tracking for this project. Covers choosing the right issue type, scope, priority, tags, and writing well-structured descriptions that match the team's conventions.
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.
Update kotlinx-rpc documentation — version bumps, content edits, Writerside topics, KDoc, README, skills, and internal workflows. Use this skill whenever the user wants to bump the Kotlin version in docs, bump the library version, update the changelog, edit documentation topics, add a migration guide, update the version switcher, fix version references, write or update KDoc on public APIs, update the README, update Claude skills, or modify CLAUDE.md. Also trigger when the user mentions "update docs", "doc version", "release docs", "Writerside", "v.list", "changelog", "KDoc", "Dokka", "README", "skill", "CLAUDE.md", or wants to sync documentation with a new release.
| name | commit-changes |
| description | Guides commit message writing for the kotlinx-rpc project. Use this skill whenever committing code, writing commit messages, or when the user asks about commit conventions. Also use it when reviewing PRs for commit message quality. Triggers on: /commit, "commit", "commit message", "git commit", writing changelogs from commits. |
Every commit message is a single line that starts with a YouTrack issue ID. No module prefixes, no parenthesized ticket references, no bodies.
The format is enforced for bot-authored PRs by
.github/workflows/bot-pr-title.yml, which rejects any PR title that does not
match ^KRPC-[0-9]+: .+. Squash-merge makes the PR title the commit subject,
so the same pattern applies to commits.
KRPC-<number>: <Imperative verb> <what changed> (#GH-issue if exists)
Example 1:
KRPC-586: Release grpc_call deterministically in NativeClientCall
Example 2:
KRPC-572: Enable local Gradle build cache alongside remote Develocity cache
Example 3:
KRPC-252: Support type resolution in comments for protoc-gen
Example 4 (with GH-issue cross-reference):
KRPC-245: Strip common enum value prefixes (#12345)
KRPC-NNN: — colon, then a single space.git log --oneline
and on GitHub.git commit, pass a single -m
with one line; do not use -m twice and do not use a HEREDOC that produces
multiple paragraphs.Some YouTrack tickets originate from a GitHub issue. When the YT ticket links to an original GH issue, append that issue number in parentheses at the end of the subject so both trackers are reachable from the git history. Check the YouTrack ticket for a linked GH issue before committing; if one exists, add it. This is not the PR number — squash-merge appends that separately, and a linked GH issue and the merge PR are different numbers.
Example: KRPC-245: Strip common enum value prefixes (#12345)
If there is no linked GH issue, omit the suffix entirely.
Older commits used grpc:, pb:, compiler-plugin: prefixes, sometimes with
the ticket tacked on in parentheses at the end. Do not copy that style. The
ticket ID comes first; the subject text itself already names the area being
changed (e.g. "Release grpc_call deterministically in NativeClientCall" makes
it obvious this touches gRPC native-client code).
If a change needs committing but no YouTrack issue exists, create one first.
The workflow check has no fallback — there is no prefix-less style for
committed work, and release/version-bump commits are not an exception. Use the
file-youtrack-issue skill to create a ticket, then commit against it.
Exception — user interaction. If the user explicitly asks to commit, and there is no ticket in the conversation context, do so without a pushback. All other rules still apply (single line, no body, imperative mood, no trailing period, ~72 chars).
This only applies when a user asks to commit, not when you have decided to commit based on other rules/skills.
GitHub automatically appends (#NNN) when squash-merging. Do not add PR
numbers to commit subjects by hand.
Never hand-edit generated files. Always run the appropriate regeneration task
and commit the output. Keep generated-file changes in a separate commit
from hand-authored code so reviewers can distinguish mechanical output from
real edits. Both commits still follow the KRPC-NNN: subject rule.
KRPC-<number>: <Imperative verb> <what changed> (#GH-issue if exists)
│ │ │
│ │ └─ Optional: linked GH issue from the YT ticket
│ └─ Capitalized, imperative mood, no period, single line
└─ Required YouTrack ticket, followed by ": "
Good: KRPC-583: Reduce configuration phase overhead from settings plugins
Good: KRPC-574: Make BufGenerateTask cacheable
Good: KRPC-576: Fix native test process crash on linuxX64 in negative test paths
Bad: grpc: Fix retry behavior (KRPC-586) — module prefix, ticket at the end
Bad: KRPC-123: fixed bug — past tense, lowercase first word
Bad: KRPC-123: Add timeout support. — trailing period
Bad: Any multi-line message — bodies are not used on this project