Commits

SkillCommunication

Create, amend, or rename IntelliJ commits and write commit messages.

Available today. Use it from your connected AI after setup.

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/intellij-community 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

  1. Review the full diff (staged + unstaged) before writing the message.
  2. Identify the motivation: why is this change being made?
  3. Write a subject line: ticket + concise summary (subsystem is not needed when a ticket is present), or label + subsystem + concise summary.
  4. 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-push skill 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, or misc.
  • 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!, or amend!.

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
21k
Forks
6k
Last commit
Sep 2026

Others that do the same job

Advanced
Catalog kind
skill
Gateway key
commits-jetbrains
Source
github.com/jetbrains/intellij-community