Commits
SkillCommunicationUse 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.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Commits skill
What this skill tells your AI
The instructions your AI receives, as published by jetbrains/mps in .agents/skills/commits/SKILL.md and read by ahel’s review.
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
Signals
- GitHub stars
- 2k
- Forks
- 309
- Last commit
- Sep 2026
ahel recommends instead
Advanced
- Catalog kind
- skill
- Gateway key
commits-2- Source
- github.com/jetbrains/mps