From fa90b2e8175622dbefe93df49f809eae3dbb6593 Mon Sep 17 00:00:00 2001 From: Dmitry Dementiev Date: Fri, 11 Sep 2026 12:24:52 +0300 Subject: [PATCH] =?UTF-8?q?docs(skills):=20=D1=83=D0=BF=D1=80=D0=BE=D1=89?= =?UTF-8?q?=D0=B5=D0=BD=D1=8B=20=D0=BF=D1=80=D0=B0=D0=B2=D0=B8=D0=BB=D0=B0?= =?UTF-8?q?=20=D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B9=20?= =?UTF-8?q?=D0=BA=D0=BE=D0=BC=D0=BC=D0=B8=D1=82=D0=BE=D0=B2?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Зачем: сохранён общий стиль сообщений без избыточных ограничений для модели. - Что: тело стало гибким, уточнены условия вызова и требования к amend; убраны повторения и пошаговые инструкции. - Проверка: quick_validate.py и git diff --check пройдены. --- .../skills/conventional-commits/SKILL.md | 101 ++++-------------- 1 file changed, 21 insertions(+), 80 deletions(-) diff --git a/agents/.agents/skills/conventional-commits/SKILL.md b/agents/.agents/skills/conventional-commits/SKILL.md index 0c4db3e..8e5f902 100644 --- a/agents/.agents/skills/conventional-commits/SKILL.md +++ b/agents/.agents/skills/conventional-commits/SKILL.md @@ -1,96 +1,37 @@ --- name: conventional-commits -description: "ОБЯЗАТЕЛЬНО вызывай этот навык каждый раз, когда пользователь просит сделать коммит, написать сообщение для git, зафиксировать изменения или проанализировать git diff. Навык содержит критически важные правила формата Conventional Commits" +description: "Формат сообщений Conventional Commits. Применяй при создании коммита, amend или подготовке сообщения коммита." --- -# Твоя роль -Ты — педантичный Release Manager и Senior Engineer. Твоя единственная задача — анализировать изменения в коде (diff) и формировать строго структурированные git-коммиты. +# Формат сообщения -# Правила заголовка -* Формат: `(): <описание>` -* Длина: не более 72 символов. -* Типы (type): feat, fix, refactor, docs, test, chore, ci, perf. -* Грамматика (Русский): совершенный вид, прошедшее время (добавлено, исправлено). -* Грамматика (Английский): повелительное наклонение (add, fix, update). Без точки в конце. -* Технические термины (SQL, DWH, PostgreSQL, Airflow) не переводи. +## Заголовок -# Шаблон тела коммита (Markdown-список) -- Зачем: - - [Бизнес-причина или техническая необходимость] -- Что: - - [Ключевое изменение 1] - - [Ключевое изменение 2, если есть] -- Проверка: - - [Как проверить: команда, тест или скрипт] +- Формат: `(): <описание>`. Указывай scope, когда он помогает обозначить область изменения. +- Типы: feat, fix, refactor, docs, test, chore, ci, perf, build, revert. +- До 72 символов, без точки в конце. +- По умолчанию пиши по-русски, в совершенном виде и прошедшем времени: «добавлено», «исправлено». Если нужен английский — используй повелительное наклонение: add, fix, update. -Требования к телу: -* Всегда используй именно список с маркерами `-`, как в шаблоне выше. -* Обязательные секции: `Зачем`, `Что`, `Проверка`. -* Внутри каждой секции минимум 1 подпункт. -* В секции `Что` обычно 1–3 подпункта с фактами по diff. +## Тело -# Правило переносов строк -В тексте коммита должны быть реальные переносы строк. Не пиши буквальные `\n`, `\r`, `\t` как часть текста сообщения. +Для простой правки достаточно заголовка. Когда нужны подробности, ориентируйся на короткий список «Зачем / Что / Проверка»: -# Специфические правила для Amend -Если пользователь просит дополнить коммит (`amend`), твоя задача — обновить сообщение так, чтобы оно выглядело как единое целое. +- Зачем: причина изменения из контекста задачи. +- Что: существенные изменения, которые дополняют заголовок. +- Проверка: что проверено и с каким результатом; предложенную проверку явно обозначай как ещё не выполненную. -1. **Сбор контекста:** Прочитай старое сообщение (`git log -1 --pretty=%B`) и оцени весь объем изменений (`git diff HEAD~1`). -2. **Секция "Зачем":** НИКОГДА не меняй эту секцию из старого коммита. -3. **Секция "Что":** Сгенерируй этот список ЗАНОВО для всего итогового кода. -4. **Секция "Проверка":** Оставь старую, либо обнови, если тесты изменились. +Сохраняй этот порядок и названия там, где они уместны. Включай только содержательные пункты; объём пояснений соразмеряй изменению. Если причина неизвестна, опирайся на подтверждённые факты. -# Примеры +Пример: -Пример 1 (Русский, новая фича, PowerShell): -@' -feat(sql): добавлен скрипт валидации данных для DWH слоя - -- Зачем: - - необходима проверка целостности и уникальности перед загрузкой в хранилище. -- Что: - - создан файл 04_validation.sql. - - добавлены проверки на NULL. -- Проверка: - - psql -f dwh-modeling/sql/04_validation.sql. -'@ | git commit -F- - -Пример 2 (Русский, багфикс): -git commit -F- <<'EOF' +```text fix(airflow): увеличен таймаут подключения ClickHouse -- Зачем: - - DAG падал с ошибкой таймаута при ночной пакетной загрузке. -- Что: - - параметр conn_timeout изменен с 30 до 120 секунд. -- Проверка: - - тестовый запуск таски в Airflow UI. -EOF +- Зачем: ночная загрузка прерывалась по таймауту подключения. +- Что: conn_timeout увеличен с 30 до 120 секунд. +- Проверка: ещё не выполнена; нужен тестовый запуск DAG. +``` -Пример 3 (Английский, lang:en): -git commit -F- <<'EOF' -refactor(docker): optimize postgres-bookings image size +## Amend -- Зачем: - - reduce deployment time and registry storage costs. -- Что: - - switched base image to alpine. - - removed intermediate build artifacts. -- Проверка: - - docker build and check image size. -EOF - -Пример 4 (Русский, логика amend): -Исходный коммит содержал только изменение `conn_timeout` до 120 секунд. -Пользователь делает amend и добавляет пропущенный файл конфига `airflow_local_settings.py`. - -Сообщение (в `.git_commit_msg.tmp`): -fix(airflow): увеличен таймаут подключения ClickHouse и обновлен конфиг - -- Зачем: - - DAG падал с ошибкой таймаута при ночной пакетной загрузке. -- Что: - - параметр conn_timeout изменен с 30 до 120 секунд. - - настройки таймаута применены на уровне воркеров в airflow_local_settings.py. -- Проверка: - - тестовый запуск таски в Airflow UI. +Сообщение описывает весь итоговый состав коммита. Перепиши его как единое целое; сохраняй исходную причину, пока она соответствует изменениям. Сведения о проверках должны относиться к итоговой версии.