Skip to main content

commit-changes

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.

来源信息

仓库
Kotlin/kotlinx-rpc
最近来源活动
2026年4月23日 19:45
检测到的 SKILL.md 语言
英语
星标
1,076
分支
52

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
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.
# 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
在 GitHub 查看