---
name: commit-component
description: Формирует коммит по docs/ai/commits.md для текущих незакоммиченных изменений в triplex-next — проверяет git status, формирует сообщение в формате "TRIPLEX-XXX Описание", делает коммит. Запускается только по явной просьбе пользователя.
---

# commit-component

Делает коммит текущих изменений по конвенциям `docs/ai/commits.md`.

## Когда запускать

**Только когда пользователь явно попросил коммитить.** В memory пользователя есть правило «не создавать коммиты без запроса» — его нельзя нарушать. Если есть малейшее сомнение — спроси.

## Воркфлоу

### 1. Проверка состояния

Запусти параллельно:
```bash
git status              # без -uall — на больших репах ест память
git diff                # текущие unstaged изменения
git diff --staged       # staged изменения
git log -5 --oneline    # стиль последних коммитов
git rev-parse --abbrev-ref HEAD   # текущая ветка
```

Имя ветки должно быть в формате `TRIPLEX-XXX-краткое-описание` (см. `docs/ai/commits.md`). Извлеки `TRIPLEX-XXX` для коммита.

### 2. Анализ изменений

Раздели изменения на категории:
- Затронутые компоненты (`src/components/{Name}/...`)
- Stories (`stories/...`)
- Тесты (`src/components/{Name}/__tests__/...`)
- Документация (`docs/ai/...`, `*-ai.md`, release notes)
- Конфиги (eslint, vitest, storybook, ci)

Определи характер:
- **Add** — новый компонент / новый prop / новая story
- **Update** — изменение существующего поведения
- **Fix** — багфикс
- **Refactor** — рефакторинг без изменения публичного API (типичный AI refactoring)
- **Docs** — только документация / AI.md / release notes

### 3. Проверка безопасности

**Никогда не коммить:**
- `__screenshots__/*.png` если изменения локальные (macOS) — pre-commit hook должен заблокировать, но проверь сам.
- `.env*` файлы.
- `node_modules/`, `dist/`, `storybook-static/` — должны быть в `.gitignore`.
- Случайно сгенерированные временные файлы (`*.log`, `tmp.*`, IDE-specific).

Если в `git status` видишь подозрительный файл — **спроси пользователя**, не добавляй автоматически. Если файл не должен трекаться — предложи добавить в `.gitignore`.

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

```text
TRIPLEX-XXX Краткое описание (≤72 символа)
```

Если нужно уточнение — двоеточие:
```text
TRIPLEX-XXX Component: уточнение
```

Примеры:
```text
TRIPLEX-901 Добавить компонент Badge с темами и размерами
TRIPLEX-912 Button: исправить стиль фокуса в теме Link
TRIPLEX-844 List: AI refactoring + unit-тесты на ListItem
TRIPLEX-844 List: добавить List-ai.md и Storybook examples
```

**Правила:**
- Первая строка ≤72 символов.
- Тело — опционально, для сложных изменений.
- Язык — русский **или** английский, не смешивать.
- Фокус — на «что» и «почему», не на «как».
- Не добавляй `Co-Authored-By: Claude` для этого проекта (в `docs/ai/commits.md` не предусмотрено).

### 5. Стейджинг и коммит

```bash
git add <конкретные файлы>     # не git add -A / git add .
git commit -m "TRIPLEX-XXX ..."
```

**Никогда не используй:**
- `git add -A` или `git add .` — может добавить sensitive/temp файлы.
- `--no-verify` — обходит linter/husky, нарушает требования проекта.
- `--amend` без явной просьбы пользователя.

### 6. Pre-commit hook

`husky` + `lint-staged` запустят `eslint --fix` и `prettier --write` на staged-файлах автоматически. Если упало:
1. Прочитай ошибку — это **не автофиксимое** ESLint-нарушение.
2. **Не используй `--no-verify`.** Исправь руками.
3. Пере-stage: `git add <files>`.
4. Создай **новый** коммит (не amend — амендить значит переписать предыдущий, который при упавшем хуке не создался; но если коммит был частично создан, амендить может потерять работу).

### 7. После коммита

```bash
git status   # подтверди успех
git log -1 --oneline
```

Покажи пользователю:
- Хеш коммита и одну строку сообщения.
- Что попало в коммит (список файлов).

**Не пушь автоматически.** Push — только по отдельной явной просьбе.

## Жёсткие ограничения

- **Не запускай без явного запроса пользователя** на коммит.
- **Не коммить, если есть несохранённые/неотревьюенные изменения**, о которых пользователь может не знать. Если файлов в `git status` больше, чем ожидалось — сначала спроси.
- **Не коммить, если упали проверки** (tsc errors, failing tests). Сначала чини, потом коммит.
- **Не делай несколько коммитов** за один запуск без подтверждения. Один запуск = один коммит, если иное не оговорено.
- **Не пушь.** Push — отдельный шаг по отдельной просьбе.

## Если что-то странное в `git status`

Не пытайся «привести в порядок» автоматически. Покажи `git status` пользователю и спроси, как поступить:

- Незнакомые untracked файлы — может быть work-in-progress, который пользователь не закончил.
- Изменения в файлах, которые не имеют отношения к задаче — могут быть случайными правками.
- Состояние rebase/merge in progress — не вмешивайся, сообщи пользователю.

## Что включает «один коммит»

Связные изменения по одной задаче. Для типичной Phase 1 итерации по компоненту — это:
- Правки в `src/components/{Name}/`
- Тесты в `src/components/{Name}/__tests__/`
- Stories в `stories/.../{Name}/`
- `src/components/{Name}/{Name}-ai.md`
- Обновление `docs/ai/ROADMAP.md` (галочки)
- При breaking change — `stories/release-notes/v1/<версия>.mdx`

Всё это укладывается в один коммит `TRIPLEX-XXX {Name}: AI-Ready` или аналогичный.