Git commit planner

Skill goldenprofile/llm-skills/git-commit-planner

LLM Skills

Install

npx -y skills add goldenprofile/llm-skills --skill git-commit-planner

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.

What its author says it does

Copied from the file, not written here

Анализирует изменения в git и строит план логических атомарных коммитов, чтобы избежать одного монолитного коммита. Используй когда пользователь собирается закоммитить много изменений, просит «разбить на логические коммиты», «атомарные коммиты», «организовать коммиты», или когда в репозитории большое число staged/unstaged/untracked файлов.

SKILL.md

11.1 KB, as published. Nobody here has run it

Git Commit Planner

Анализирует изменения в git-репозитории и строит структурированный план логических атомарных коммитов вместо одного большого монолитного коммита.

Когда применять

В репозитории много незакоммиченных изменений в разных файлах/модулях
Пользователь просит «закоммить изменения» или «организуй коммиты»
Нужно разбить крупные изменения на логические группы
Упоминаются «логические коммиты», «атомарные коммиты», отказ от «больших коммитов»

Согласование с git-workflow проекта

Следуй формату коммитов из ~/.claude/CLAUDE.md (git-workflow):

Conventional Commits, разрешённые типы: feat, fix, refactor, docs, test, chore, perf, ci.
Формат: <type>: <описание> (опционально со scope: <type>(<scope>): <описание>).
Описание коммита — на русском языке.
Attribution отключён глобально — НЕ добавлять Co-Authored-By и подобные трейлеры.

Разрешения на команды

Следующие read-only git-команды выполняются без запроса подтверждения — они безопасны и не меняют состояние репозитория:

git status / git status --porcelain
git diff (любые варианты: --stat, --cached, с путями)
git log (любые варианты: --oneline, -N, с форматированием)
git ls-files

Процесс анализа

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

Запусти эти команды параллельно для сбора информации.

PowerShell (Windows):

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

Bash (Linux/Mac):

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

Коды статуса файлов:

A — новый файл, staged
M — изменён, не staged
M — изменён, staged
MM — изменён и в staged, и в working directory
AM — новый файл с дополнительными unstaged-изменениями
?? — untracked
D — удалён, не staged
D — удалён, staged

Шаг 2. Логическая группировка изменений

Группируй файлы по:

Фиче/модулю — изменения одного модуля или фичи
Типу изменения — документация, новые фичи, рефакторинг, баг-фиксы, тесты, конфигурация
Зависимостям — файлы, которые нужно коммитить вместе
Области влияния — инфраструктура, ядро, конкретное приложение, UI

Стратегия планирования коммитов

Порядок приоритета групп

Документация и конфигурация — README, docs, конфиги
Инфраструктура/ядро — новые системы, крупные рефакторы
Новые модули/фичи — целостная новая функциональность
Обновления приложений — изменения существующих приложений
Тесты — новые или обновлённые
Шаблоны и статика — UI-изменения
Мелкие фиксы — небольшие правки, чистка

Размер коммита

Идеально: 5-50 файлов на коммит
Допустимо: до 100 файлов, если логически связаны
Избегать: смешивания несвязанных изменений, даже мелких

Формат сообщения коммита

Conventional Commits, описание на русском, без Co-Authored-By:

<type>(<scope>): <краткое описание на русском>

- Деталь 1
- Деталь 2

Разрешённые типы: feat (новая функциональность), fix (исправление бага), refactor (рефакторинг), docs (документация), test (тесты), chore (служебные задачи), perf (производительность), ci (CI/конфигурация сборки).

Формирование плана

Представь план нумерованным списком: номер и заголовок коммита, задействованные файлы (сгруппированы), git-команды, краткое обоснование группировки.

Примеры команд коммита

PowerShell (Windows):

git add file1.py file2.py folder/
git commit -m "feat(module): добавлена новая фича" -m "- Добавлено X" -m "- Обновлены связанные файлы"

Bash (Linux/Mac):

git add file1.py file2.py folder/
git commit -m "feat(module): добавлена новая фича" \
  -m "- Добавлено X" \
  -m "- Обновлены связанные файлы"

Примечание: используй несколько флагов -m вместо heredoc для кросс-платформенной совместимости.

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

MM (смешанные изменения): файлы со статусом MM имеют и staged-, и unstaged-изменения. Реши, нужно ли включать unstaged. git add <file> застейджит всё; git restore --staged <file> снимет со стейджа для выборочного добавления.

Удалённые файлы (MD, D ): используй git rm <file> для стейджа удаления.

Untracked (??): определи, нужно ли файл добавить (git add), игнорировать (.gitignore) или удалить с диска.

Большие первые коммиты: при добавлении многих новых файлов (начальные шаблоны, статика) допустимы крупные коммиты. Группируй по функциональным областям (все admin-шаблоны, весь CSS), указывай «initial»/«add» в сообщении.

Типовые паттерны группировки

Django/Python: документация → конфигурация (settings.py, requirements.txt, pyproject.toml) → ядро (новые приложения, базовые классы, утилиты) → отдельные приложения (один коммит на приложение/фичу) → шаблоны по секциям → статика.

JavaScript/Node: конфигурация пакетов (package.json, lock-файлы) → сборка/тулинг (webpack, babel) → исходники по фичам → компоненты по областям → стили и ассеты → тесты.

Анти-паттерны

Не делай: не смешивай документацию с кодом; не объединяй несвязанные фичи; не разделяй логически связанные файлы; не плоди крошечные коммиты для мелких правок одного файла; не включай закомментированный код и debug-вывод.

Делай: держи связанные изменения вместе; пиши понятные сообщения; учитывай будущую code archaeology (когда/зачем изменилось); группируй по принципу «что захочется откатить как единое целое».

Отслеживание прогресса

После каждого коммита: git status --short (проверка), git log --oneline -1 (коммит создан), переход к следующей группе.

Финальная проверка после всех коммитов:

git status              # ожидается "nothing to commit, working tree clean"
git log --oneline -N    # обзор последних N коммитов

Автономное выполнение

ВАЖНО: после того как пользователь одобрил план коммитов, выполняй все коммиты автономно без дополнительных подтверждений. Не спрашивай разрешения на каждую команду git add / git commit — выполняй весь согласованный план последовательно и покажи итоговый результат.

Формат вывода плана

## План коммитов: [Проект]

Найдено [X] изменённых файлов, [Y] новых файлов, [Z] удалённых файлов.

### Коммит 1: Обновление документации
**Файлы:** README.md, docs/api.md, CHANGELOG.md
**Команда:**
git add README.md docs/api.md CHANGELOG.md
git commit -m "docs: обновление документации проекта" -m "- Обновлён README" -m "- Добавлена документация API"

### Коммит 2: Инфраструктура ядра
**Файлы:** src/core/base.py, src/utils/helpers.py
**Команда:**
git add src/core/ src/utils/
git commit -m "refactor(core): улучшение базовых классов и утилит"

[... продолжение для всех коммитов ...]

### Итого
- Запланировано коммитов: [N]
- Файлы сгруппированы по: [стратегия]