git-conventional-commits · diff
git:20260808.51f4ff4 to git:20260809.d00d280
100 added, 0 removed. Audit C to A.
+ ---
+ name: git-conventional-commits
+ description: >
+ Формирует commit-сообщение по Conventional Commits для текущих изменений в git.
+ Анализирует staged-diff (или unstaged, если staged пуст), определяет type/scope,
+ пишет subject и при необходимости тело. Используй, когда пользователь хочет
+ «сделать коммит», «закоммитить изменения», «commit это», «сформулируй commit-message»,
+ «commit по конвенции».
+ ---
+ # git-conventional-commits — 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 в блоке. Спроси:
+ 1. Принять как есть → `git commit -m "..."`
+ 2. Поправить subject/тело
+ 3. Разбить на несколько коммитов
+ 4. Отменить
+
+ **Не запускай `git commit` без подтверждения пользователя.**
+
+ ## Шаг 7. Выполни
+
+ После подтверждения:
+ - если subject короткий (одностроковый) — `git commit -m "..."`
+ - если есть тело — используй `git commit -F -` с heredoc, либо временный файл
+
+ Покажи результат `git log -1 --stat`.
+
+ ## Чего не делать
+
+ - Не предлагай `chore: update` — это пустое сообщение
+ - Не объединяй несвязанные изменения в один коммит
+ - Не используй `feat` для багфиксов и наоборот
+ - Не пиши «WIP» в финальном коммите — для WIP есть `git commit --fixup` и rebase позже