PrompTom
Усі скіли

Commit message

commit-messagegitcommits

Writes the message from what is actually staged, and explains why rather than what.

Що робить

  • Triggers when you ask to commit or ask for a commit message.
  • Reads the staged diff first instead of trusting its memory of what it did. Subject under 72 characters, imperative, no full stop.
  • The body explains what was broken and why this approach. It does not list changed files — git show --stat does that better.
  • If the staged changes mix two unrelated things, it says so and offers to split them.

Навіщо він потрібен

Commit history matters six months later, when you're hunting where a bug came from. “Various fixes” is useless at that moment, and the why is the one thing a diff can never tell you.

Куди покласти

  1. 1Створіть у проєкті теку .claude/skills/commit-message
  2. 2Покладіть у неї файл SKILL.md з текстом нижче
  3. 3Усе. Claude Code підключить скіл сам, коли задача підійде під опис

Щоб скіл працював в усіх проєктах, а не в одному, покладіть його в ~/.claude/skills замість теки проєкту.

Файл SKILL.md

---
name: commit-message
description: Write the commit message for the staged changes. Use when the user asks to commit, asks for a commit message, or says the work is ready to commit.
---

# Writing the commit message

Read the staged diff first — `git diff --cached`. Never write a message
from memory of what you did; write it from what is actually staged.

## The subject line

One line, imperative mood, no trailing full stop. Name the change, not
the files. "Fix the button that scrolled nowhere" beats "Update page.tsx".

Keep it under 72 characters so it doesn't wrap in `git log`.

## The body

Explain **why**, not what. The diff already says what changed; it cannot
say what was wrong before, or what would break if this were done
differently.

Answer these, in prose, only where they apply:

- What was broken or missing, described concretely enough that someone
  hitting the same problem would recognise it.
- Why this approach and not the obvious alternative.
- What is deliberately not covered, and why.

Wrap the body at 72 characters.

## What not to write

- Do not list the changed files. `git show --stat` does that better.
- Do not write "various fixes", "improvements", "refactoring" — these
  say nothing and make the history useless when someone bisects it.
- Do not restate the subject line in the body.
- Do not mention the tools or the model that produced the change.

## Before committing

Check that the staged diff contains only what belongs in this commit.
If it mixes two unrelated changes, say so and offer to split them.
Commit message — PrompTom