agentleFS
KotlinKotlin/kotlinx-rpc/.claude/skills/commit-changes/SKILL.md

commit-changes

Skill1.1k starsChanged 5 days agoApache-2.0View on GitHub

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.

We split this skill into the rules it gives an agent

9 rules. 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Every commit message is a single line that starts with a YouTrack issue ID.

    line 12
  2. Distinctive:

    No module prefixes, no parenthesized ticket references, no bodies.

    line 13
  3. Distinctive:

    Capitalize the first word: after the colon.

    line 43
  4. Distinctive:

    Check the YouTrack ticket for a linked GH issue before committing.

    line 58
  5. Distinctive:

    If there is no linked GH issue, omit the suffix entirely.

    line 64
  6. Distinctive:

    If a change needs committing but no YouTrack issue exists, create one first.

    line 76
  7. Distinctive:

    Exception — user interaction: If the user explicitly asks to commit, and there is no ticket in the conversation context, do so without a …

    line 81
  8. Distinctive:

    All other rules still apply (single line, no body, imperative mood, no trailing period, ~72 chars).

    line 83
  9. Distinctive:

    Never hand-edit generated files.

    line 96

“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

kotlinx-rpc Commit Message Style

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.

Format

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)

Rules

  1. Start with the YouTrack ID as KRPC-NNN: — colon, then a single space.
  2. English only.
  3. Imperative mood, present tense — "Fix" not "Fixed", "Add" not "Added".
  4. Capitalize the first word after the colon.
  5. No trailing period.
  6. Keep under ~72 characters so it stays readable in git log --oneline and on GitHub.
  7. No body, ever. Everything a reviewer needs goes on the subject line. 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.

GitHub issue cross-references

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.

No module prefixes

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

No YouTrack ticket yet?

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.

PR numbers

GitHub automatically appends (#NNN) when squash-merging. Do not add PR numbers to commit subjects by hand.

Generated files

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.

Quick reference

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

Download now (ZIP)

Trending

Quiet since September.about the whole repository

Dec 2025: 2 mentionsJan 2026: 1 mentionFeb 2026: 0 mentionsMar 2026: 1 mentionApr 2026: 0 mentionsMay 2026: 1 mentionJun 2026: 2 mentionsJul 2026: 2 mentionsAug 2026: 0 mentionsSep 2026: 1 mentionOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the Kotlin/kotlinx-rpc repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about Kotlin/kotlinx-rpc

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

11 more on GitHub

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.