> 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. "commit", "commit message", "git commit", writing changelogs from commits.
npx skills add https://github.com/Kotlin/kotlinx-rpc --skill commit-changes
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 --onelineand on GitHub.
Longer context belongs in the YouTrack ticket or the PR description —
never in the commit body. When invoking 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
Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping
Comprehensive GitHub code review with AI-powered swarm coordination
Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits.
Comprehensive truth scoring, code quality verification, and automatic rollback system with 0.95 accuracy threshold for ensuring high-quality agent outputs and codebase reliability.
GitHub CLI (gh) comprehensive reference for repositories, issues, pull requests, Actions, projects, releases, gists, codespaces, organizations, extensions, and all GitHub operations from the command line.
GitHub CLI - manage repositories, issues, pull requests, actions, releases, and more from the command line.
You are a code refactoring expert specializing in clean code principles, SOLID design patterns, and modern software engineering best practices. Analyze and refactor the provided code to improve its quality, maintainability, and performance.
You are a technical debt expert specializing in identifying, quantifying, and prioritizing technical debt in software projects. Analyze the codebase to uncover debt, assess its impact, and create acti
Take kotlin/commit-changes from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
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.