Git Commit Planner

Разбирает накопившиеся изменения и строит план атомарных коммитов. Нужен, когда изменений много и они из разных областей; для двух-трёх связанных правок план избыточен — коммить сразу.

Формат сообщений, разрешённые типы и запрет трейлеров — правило проекта, оно живёт в CLAUDE.md и действует независимо от этого навыка. Здесь — только процедура группировки.

Шаг 1. Состояние репозитория

git status --porcelain
git ls-files --others --exclude-standard
git log --oneline -10

Последняя команда нужна, чтобы новые сообщения попадали в стиль уже принятый в этом репозитории, а не в абстрактно правильный.

Шаг 2. Группировка

Режь по границам, а не по типам файлов. Главный критерий — «что захочется откатить как единое целое». Дальше по убыванию:

1. Фича или модуль — изменения, которые вместе имеют смысл и вместе ломаются.
2. Тип изменения — документация, фича, рефакторинг, фикс, тесты, конфигурация.
3. Жёсткая зависимость — файлы, порознь оставляющие проект сломанным, идут в один коммит обязательно.

Шаг 3. Порядок коммитов

От фундамента к листьям, чтобы каждый коммит оставлял дерево рабочим:

документация и конфигурация → инфраструктура и ядро → новые модули → изменения существующих модулей → тесты → шаблоны и статика → мелкие правки.

Типовые разрезы: Django — settings/зависимости, затем ядро, затем по одному коммиту на приложение, затем шаблоны и статика. Node — package-файлы, затем тулинг, затем исходники по фичам, затем стили и тесты.

Шаг 4. План

Выдай нумерованный список: заголовок коммита, файлы, готовая команда, однострочное обоснование группировки. В конце — сколько коммитов и по какому принципу разрезано.

После одобрения плана выполняй его автономно, не спрашивая подтверждения на каждый git add. После каждого коммита — git status --short; в конце дерево должно быть чистым.

Особые случаи

• MM / AM — у файла есть и staged-, и unstaged-часть. Решить, входит ли unstaged в этот коммит, а не стейджить вслепую.
• ?? — определить: добавить, внести в .gitignore или удалить с диска. Untracked-мусор в коммит не попадает молча.
• Много новых файлов сразу (начальные шаблоны, статика) — крупный коммит допустим, но группируй по функциональным областям.
• Изменения, которые вообще не надо коммитить — отладочный вывод, закомментированный код, локальные конфиги: назови их отдельно, не прячь в общую группу.

Границы

Только планирование и выполнение коммитов. Определение версии, CHANGELOG и тег — release-manager. Ревью содержимого изменений перед коммитом — change-review или /code-review.