Git conventional commit

Skill jtprogru/bear-skills/skills/git-conventional-commit

Формирует commit-сообщение по Conventional Commits для текущих изменений в git. Анализирует staged-diff (или unstaged, если staged пуст), определяет type/scope, пишет subject и при необходимости тело. Используй, когда пользователь хочет «сделать коммит», «закоммитить изменения», «commit это», «сформулируй commit-message», «commit по конвенции».From its SKILL.md

Install

npx -y skills add jtprogru/bear-skills --skill git-conventional-commit

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.9 KB, as published. Nobody here has run it

git-conventional-commit — Conventional Commit message для текущего diff

Цель: вместо того чтобы пользователь сам формулировал commit-message, ты анализируешь diff и формируешь сообщение по конвенции ../../rules/git-conventions.md.

Перед началом прочитай ../../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 позже