jtprogru git-conventional-commit — Conventional Commit message для текущего diff
Цель: вместо того чтобы пользователь сам формулировал commit-message, ты анализируешь diff и формируешь сообщение по конвенции ~/.claude/rules/git-conventions.md.
Перед началом прочитай ~/.claude/rules/git-conventions.md — там полный список допустимых type, формат scope и принципы.
Шаг 1. Собери контекст
Запусти:
git status --short— посмотри, что измененоgit diff --staged(если есть staged) илиgit diff(если нет) — содержание измененийgit log --oneline -10— стиль предыдущих коммитов в проекте (особенно язык: русский/английский)
Если staged пуст и unstaged тоже — скажи пользователю и остановись.
Шаг 2. Определи type
Прочитай diff и реши:
| diff показывает | type |
|---|---|
| новый файл с функциональностью, новый endpoint, новая фича | feat |
| правка логики, чтобы баг перестал воспроизводиться | fix |
| перенос/переименование/упрощение без изменения поведения | refactor |
| только улучшение производительности | perf |
только .md, комментарии в коде |
docs |
| только тесты добавлены или поправлены | test |
package.json, go.mod, requirements.txt, Dockerfile, CI-конфиги |
build или ci |
| зависимости, версии тулинга | chore(deps) |
| откат предыдущего коммита | revert |
Если diff смешанный (например, и fix и refactor) — остановись и предложи пользователю разбить на несколько коммитов. Не пиши «feat: исправил баг и отрефакторил» — это анти-паттерн.
Шаг 3. Определи scope (опционально)
Scope — короткое имя модуля/папки/SDK. Эвристика:
- если все файлы под одной папкой первого уровня (
src/auth/,sdk-go/,cli/) — scope = имя этой папки - если затронуто 2-3 файла в разных папках — scope можно опустить
- если поправлен один конкретный компонент (
UserCard.tsx) — scope = имя компонента в kebab-case
Шаг 4. Сформулируй subject
- 50-72 символа
- глагол в настоящем времени, без заглавной буквы, без точки
- если коммиты в проекте на русском — пиши на русском, если на английском — на английском (смотри
git log) - субъект описывает что изменилось, не «что я сделал»
Плохо: feat: добавил новый эндпоинт для логина пользователей
Хорошо: feat(auth): добавить endpoint POST /login
Шаг 5. Тело и футер (если нужны)
Тело пиши, если:
- изменение неочевидно из subject — объясни зачем
- есть breaking change — обязательно
- есть ссылки на issue/тикет
Формат:
<type>(<scope>): <subject>
<body — что/зачем, 2-5 предложений>
BREAKING CHANGE: <что ломается и как мигрировать>
Refs: #123
Шаг 6. Покажи и спроси
Покажи пользователю предложенный commit-message в блоке. Спроси:
- Принять как есть →
git commit -m "..." - Поправить subject/тело
- Разбить на несколько коммитов
- Отменить
Не запускай git commit без подтверждения пользователя.
Шаг 7. Выполни
После подтверждения:
- если subject короткий (одностроковый) —
git commit -m "..." - если есть тело — используй
git commit -F -с heredoc, либо временный файл
Покажи результат git log -1 --stat.
Чего не делать
- Не предлагай
chore: update— это пустое сообщение - Не объединяй несвязанные изменения в один коммит
- Не используй
featдля багфиксов и наоборот - Не пиши «WIP» в финальном коммите — для WIP есть
git commit --fixupи rebase позже