Denozordec
5fca165c69
CI / changes (push) Successful in 10s
CI / commitlint (push) Has been skipped
CI / openapi (push) Successful in 25s
CI / web (push) Successful in 36s
CI / go (push) Successful in 49s
CI / bird2 (push) Successful in 17s
CI / release (push) Successful in 3m59s
- Merged birdSettingsSchema and revisionSettingsSchema into settingsKnownSchema, marking the previous schema as deprecated. - Updated emptySettingsKnownForm to utilize emptyBirdSettingsForm and emptyRevisionSettingsForm. - Refactored layout and page components to streamline theme management and improve tab synchronization in network and operations pages. - Introduced new system settings tab in operations and updated settings page to manage theme preferences.
144 lines
7.1 KiB
Markdown
144 lines
7.1 KiB
Markdown
---
|
||
name: commit-message
|
||
description: >-
|
||
ОБЯЗАТЕЛЬНО при commit, коммит, закоммить, commit message, conventional commit,
|
||
staged, semantic-release, «сгенерируй коммит», git commit, /commit-message: ПЕРВЫМ
|
||
делом Shell — scripts/commit/staged-context.ps1; затем Conventional Commit (заголовок EN, тело RU).
|
||
---
|
||
|
||
> **Кнопка ✨ Generate commit message в Source Control** не использует этот скилл и Rules.
|
||
> Эквивалент: Agent Chat → **`/commit-message`** или «сгенерируй коммит по staged».
|
||
> См. [docs/README.md](../../docs/README.md#сообщения-коммитов-cursor).
|
||
|
||
# Commit message (EvoBGP)
|
||
|
||
## Когда применять (сразу читать этот скилл)
|
||
|
||
Триггеры в промпте пользователя или в плане/AGENTS.md:
|
||
|
||
- `commit`, `коммит`, `закоммить`, `commit message`, `conventional commit`
|
||
- `git commit`, `staged`, `сообщение коммита`, `сгенерируй коммит`
|
||
- агент собирается выполнить `git commit` или предложить текст коммита
|
||
|
||
## Шаг 0 — ОБЯЗАТЕЛЬНО (до любого текста коммита)
|
||
|
||
**Первый вызов инструментов** в этой задаче — Shell из корня репозитория:
|
||
|
||
```powershell
|
||
powershell -NoProfile -File scripts/commit/staged-context.ps1
|
||
```
|
||
|
||
| Правило | Деталь |
|
||
|---------|--------|
|
||
| **MUST** | Запустить скрипт до генерации заголовка/тела коммита |
|
||
| **MUST NOT** | Строить сообщение только по `git diff --cached` / `git status` без скрипта |
|
||
| **MUST NOT** | Пропускать скрипт, даже если diff «и так понятен» |
|
||
| Exit `1` | Index пуст — сообщить пользователю, **не коммитить** |
|
||
| Exit `0` | Разобрать JSON stdout: `staged_count`, `groups[]` (`scope`, `files`, `stat`, `diff_excerpt`) |
|
||
|
||
Дополнительно: [.cursor/rules/conventional-commits.mdc](../../rules/conventional-commits.mdc).
|
||
|
||
## Слияние групп (одна фича)
|
||
|
||
Скрипт группирует **только по путям**. Перед split проверьте логическую связность:
|
||
|
||
**Объединить в один коммит**, если это одна задача:
|
||
|
||
- `docs/openapi.yaml` + `internal/httpapi/` (+ опционально `web/`) — один endpoint/контракт;
|
||
- `migrations/` + `internal/store/` / `repository/` — одна схема;
|
||
- правки теста рядом с кодом той же фичи.
|
||
|
||
При объединении: один scope (доминирующий пакет, часто `httpapi` или `openapi`), один type, одно тело RU.
|
||
|
||
**Auto-split** — если группы **не связаны** (например `web/` + `internal/birdfmt/` без общего смысла): **отдельный коммит на группу**, без вопроса пользователю.
|
||
|
||
## Порядок коммитов при split
|
||
|
||
1. `openapi`
|
||
2. `httpapi`, `store`, `jobs`
|
||
3. `pipeline`, `birdfmt`, `birddeploy`, `bundle`
|
||
4. `web`
|
||
5. `ci`, `deploy`, `db`
|
||
6. `docs`
|
||
7. `chore`, `cmd`
|
||
|
||
## Алгоритм auto-split (уровень файлов)
|
||
|
||
1. `git status` и `git diff --cached --stat` — зафиксировать полный список staged-файлов.
|
||
2. `git reset HEAD` — снять всё из index (working tree не трогать).
|
||
3. Для каждой (объединённой) группы по порядку выше:
|
||
- `git add -- <paths…>`
|
||
- Сгенерировать сообщение по правилу conventional-commits.
|
||
- Закоммитить (см. ниже).
|
||
4. После всех коммитов — `git status` для проверки.
|
||
|
||
**Ограничение:** частичный stage одного файла с разной семантикой — предупредить; split по hunk'ам не делать; предложить разнести правки по файлам.
|
||
|
||
## Создание коммита
|
||
|
||
Только если пользователь **явно** просил закоммитить. Иначе — только вывести готовые сообщения.
|
||
|
||
```powershell
|
||
git commit -m "$( @'
|
||
<type>(<scope>): <summary in English>
|
||
|
||
<Тело на русском.>
|
||
'@ )"
|
||
```
|
||
|
||
В PowerShell для многострочного тела используйте here-string как выше или `-m` для заголовка и `-m` для тела.
|
||
|
||
Перед коммитом: `git status`, `git diff --cached` для группы — убедиться, что stage соответствует сообщению.
|
||
|
||
## Генерация текста
|
||
|
||
По `groups[].diff_excerpt`, `stat`, `files`:
|
||
|
||
### Шаг A — semver (до выбора type)
|
||
|
||
| Вопрос | Если «да» → |
|
||
|--------|-------------|
|
||
| Пользователь получает **новую** возможность? | `feat` (minor) |
|
||
| Восстанавливается **ожидаемое** поведение / устранён баг? | `fix` (patch) |
|
||
| Только скорость, контракт тот же? | `perf` (patch) |
|
||
| Только структура кода/UI, поведение то же? | `refactor` (patch) |
|
||
|
||
**Follow-up:** правки сразу после `feat` в том же scope без новой возможности → **`fix`**, не `feat` (слова *enhance/improve/refactor* в задаче не делают commit `feat`).
|
||
|
||
**Запрещено** по умолчанию ставить `feat` для «большого diff» в `web/` — type по **semver impact**, не по объёму.
|
||
|
||
### Шаг B — type, scope, текст
|
||
|
||
- **type** — результат шага A, не «chore по умолчанию» и не `feat` из-за слова enhance.
|
||
- **scope** — из JSON группы или доминирующий при merge.
|
||
- **summary** — конкретный, английский, императив; для `fix` — что **починено** (`fix broken …`, `prevent … loop`).
|
||
- **body** — русский: что, зачем, edge cases, breaking impact.
|
||
|
||
## Вывод пользователю
|
||
|
||
Для **каждого** коммита:
|
||
|
||
### 1. Готовое сообщение
|
||
|
||
```
|
||
<type>(<scope>): <summary>
|
||
|
||
<тело>
|
||
```
|
||
|
||
### 2. Пояснение (RU)
|
||
|
||
- **Semver impact:** `minor` | `patch` | `none` | `major` — и почему не другой type.
|
||
- Риски и impact.
|
||
- Split: сколько коммитов и почему.
|
||
|
||
## Не смешивать
|
||
|
||
Один commit message — одна primary intent. Не объединять несвязанный `fix` и `feat` в один заголовок.
|
||
|
||
## Ссылки
|
||
|
||
- Правило: `.cursor/rules/conventional-commits.mdc`
|
||
- Скрипт: `scripts/commit/staged-context.ps1`
|
||
- Просмотр групп: `powershell -File scripts/commit/staged-context.ps1 | ConvertFrom-Json`
|