---
name: git-commit-planner
description: >
  Анализирует изменения в git и строит план логических атомарных коммитов,
  чтобы избежать одного монолитного коммита. Используй когда пользователь
  собирается закоммитить много изменений, просит «разбить на логические
  коммиты», «атомарные коммиты», «организовать коммиты», или когда в репозитории
  большое число staged/unstaged/untracked файлов.
metadata:
  version: 1.0.0
---

# 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):
```powershell
git status --porcelain
git ls-files --others --exclude-standard
git log --oneline -10
```

Bash (Linux/Mac):
```bash
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. Логическая группировка изменений

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

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

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

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

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

Conventional Commits, описание на русском, без `Co-Authored-By`:
```
<type>(<scope>): <краткое описание на русском>

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

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

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

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

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

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

Bash (Linux/Mac):
```bash
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` — выполняй весь согласованный план последовательно и покажи итоговый результат.

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

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

Найдено [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]
- Файлы сгруппированы по: [стратегия]
```