git-conventional-commits git:20260809.d00d280A

Immutable. This exact content never changes and is served at /api/v1/blob/3152f8a8f0da4246.

---
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 позже