Agent Skills
› DetachHead/rebased
› commits
commits
GitHub规范 IntelliJ 平台代码提交,生成符合 SafePush/Patronus 验证的完整提交信息。涵盖审查差异、编写含动机的主题行与正文、处理后缀及避免反模式,确保格式合规以节省 CI 和审查时间。
触发场景
用户请求提交更改
编写或修复提交信息
修改或重命名提交
执行包含提交的 IntelliJ 工作流
安装
npx skills add DetachHead/rebased --skill commits -g -y
SKILL.md
Frontmatter
{
"name": "commits",
"description": "Use this skill whenever the user asks to commit changes, write or fix a commit message, amend or rename a commit, or do a workflow that includes committing in the IntelliJ repository. This is a thin repo-specific overlay: use IntelliJ commit format, write full commit messages by default, and keep requested suffixes such as IJ-MR trailers in a final separate paragraph."
}
Commits
Critical: SafePush/Patronus validates commit messages before allowing merges. Invalid format wastes CI time and reviewer time.
Workflow
- Review the full diff (staged + unstaged) before writing the message.
- Identify the motivation: why is this change being made?
- Write a subject line: ticket + concise summary (subsystem is not needed when a ticket is present), or label + subsystem + concise summary.
- Write a body for any non-trivial change: explain the "why", summarize key design decisions, and note any non-obvious behavioral effects. Do not just restate what the diff shows — explain what the reader cannot see from the code alone.
Source Of Truth
- Follow docs/IntelliJ-Platform/0_Intro/2_Commits.md.
- This skill is a repo-specific overlay, not a replacement for that document.
- In this repository, IntelliJ commit format takes precedence over generic commit conventions.
- Do not use Conventional Commits here.
- If the user asks to push, use the
safe-pushskill for push workflow details.
Quick Rules
- Behavioral changes need a YouTrack ticket in the subject line.
- When a ticket ID is present, omit the subsystem prefix — the ticket provides sufficient context.
- Clearly non-behavioral changes may use a non-production label such as
tests,cleanup,refactor,docs,format,style,setup, ormisc. - If there is any doubt whether the change is behavioral, do not use a non-production label.
- Write a full commit message (subject + body) for any non-trivial change. Subject-only is acceptable only for truly mechanical changes (typo, import, format).
- The body must explain why the change was made and summarize key decisions. Do not just list what files changed — the diff already shows that.
- Keep the first line concise; put rationale and important behavior notes in the body.
- If the user requests a suffix such as
IJ-MR-100, put it in a final separate paragraph after a blank line. - Do not use commits starting with
WIP,fixup!,squash!, oramend!.
Examples
MRI-3589 harden single-flight recursion checks
Track active single-flight computations in coroutine context so recursive
awaits fail fast in both the owning coroutine and child coroutines.
IJ-MR-100
tests cidr: migrate JUnit 5 coverage
Convert remaining JUnit 4 test suites under cidr/coverage to JUnit 5.
Parametrized tests now use @MethodSource instead of Theories runner.
Anti-patterns
- Subject-only messages for non-trivial changes (even non-production ones).
- Restating the diff ("changed X in file Y") instead of explaining motivation.
- Using Conventional Commits format (
fix(scope): ...).
References
版本历史
- 1f8708d 当前 2026-08-16 15:38


