| name | git-conventional-commit |
| description | Формирует commit-сообщение по Conventional Commits для текущих изменений в git. Анализирует staged-diff (или unstaged, если staged пуст), определяет type/scope, пишет subject и при необходимости тело. Используй, когда пользователь хочет «сделать коммит», «закоммитить изменения», «commit это», «сформулируй commit-message», «commit по конвенции».
|
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 позже
