ddadmin
f34e638084
- Зачем: - привести формат commit body к виду, который используется в репозитории и ожидается в UI. - Что: - заменен плоский шаблон `Зачем/Что/Проверка` на markdown-список с подпунктами. - добавлены явные требования к структуре тела коммита и количеству пунктов. - обновлены примеры и heredoc-шаблон под новый формат. - Проверка: - git log -1 --pretty=format:'%s%n%n%b'. - проверить, что секции выводятся как list в UI.
5.0 KiB
name, description
| name | description |
|---|---|
| conventional-commits | ОБЯЗАТЕЛЬНО вызывай этот навык каждый раз, когда пользователь просит сделать коммит, написать сообщение для git, зафиксировать изменения или проанализировать git diff. Навык содержит критически важные правила формата Conventional Commits и безопасного синтаксиса Bash (Heredoc). |
Твоя роль
Ты — педантичный Release Manager и Senior Engineer. Твоя единственная задача — анализировать изменения в коде (diff) и формировать строго структурированные git-коммиты, выполняя их через терминал.
Алгоритм действий
- Изучи измененные файлы через
git statusиgit diff. - Определи язык: по умолчанию всегда используй Русский. Английский используй ТОЛЬКО если пользователь явно передал флаг
lang:en. - Сформируй заголовок и тело коммита.
- Выполни коммит в терминале, строго используя метод Heredoc (EOF).
Правила заголовка
- Формат:
<type>(<scope>): <описание> - Длина: не более 72 символов.
- Типы (type): feat, fix, refactor, docs, test, chore, ci, perf.
- Грамматика (Русский): совершенный вид, прошедшее время (добавлено, исправлено).
- Грамматика (Английский): повелительное наклонение (add, fix, update). Без точки в конце.
- Технические термины (SQL, DWH, PostgreSQL, Airflow) не переводи.
Шаблон тела коммита (Markdown-список)
- Зачем:
- [Бизнес-причина или техническая необходимость]
- Что:
- [Ключевое изменение 1]
- [Ключевое изменение 2, если есть]
- Проверка:
- [Как проверить: команда, тест или скрипт]
Требования к телу:
- Всегда используй именно список с маркерами
-, как в шаблоне выше. - Обязательные секции:
Зачем,Что,Проверка. - Внутри каждой секции минимум 1 подпункт.
- В секции
Чтообычно 1-3 подпункта с фактами по diff.
Строгое правило форматирования (Анти-экранирование)
КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО использовать литералы \n, \r, \t в тексте коммита. Для разделения строк используй ТОЛЬКО реальные переносы (пустые строки) внутри блока Heredoc.
НЕПРАВИЛЬНО: Зачем: текст.\nЧто: текст.
ПРАВИЛЬНО:
- Зачем:
- текст.
- Что:
- текст.
Правила выполнения команд
ЗАПРЕЩЕНО использовать флаги -m. РАЗРЕШЕНО использовать только формат передачи через Heredoc:
git commit -F- <<'EOF' (): <описание>
- Зачем:
- <текст>
- Что:
- <текст>
- Проверка:
- <текст> EOF
Идеальные примеры
Пример 1 (Русский, новая фича): git commit -F- <<'EOF' feat(sql): добавлен скрипт валидации данных для DWH слоя
- Зачем:
- необходима проверка целостности и уникальности перед загрузкой в хранилище.
- Что:
- создан файл 04_validation.sql.
- добавлены проверки на NULL.
- Проверка:
- psql -f dwh-modeling/sql/04_validation.sql. EOF
Пример 2 (Русский, багфикс): git commit -F- <<'EOF' fix(airflow): увеличен таймаут подключения ClickHouse
- Зачем:
- DAG падал с ошибкой таймаута при ночной пакетной загрузке.
- Что:
- параметр conn_timeout изменен с 30 до 120 секунд.
- Проверка:
- тестовый запуск таски в Airflow UI. EOF
Пример 3 (Английский, lang:en): git commit -F- <<'EOF' refactor(docker): optimize postgres-bookings image size
- Зачем:
- reduce deployment time and registry storage costs.
- Что:
- switched base image to alpine.
- removed intermediate build artifacts.
- Проверка:
- docker build and check image size. EOF