# Git Commit Planner

> В рабочем дереве накопилось много несвязанных изменений — разложить их на логические атомарные коммиты вместо одного «всё сразу»: группировка по смыслу, порядок применения, готовые команды. Используй когда пользователь говорит «сделай коммиты, предварительно проанализировав изменения», «разбей на логические коммиты», «атомарные коммиты», или когда в репозитории много staged/unstaged/untracked файлов сразу из разных областей. Версия, CHANGELOG и тег релиза — release-manager.

- Skill: `goldenprofile/git-commit-planner` (Agent Skill)
- Install (CLI): `npx skillmds@latest add goldenprofile/git-commit-planner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/goldenprofile/git-commit-planner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: goldenprofile (https://skillmd.com/u/goldenprofile)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/goldenprofile/git-commit-planner

---


# 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`.