git-pr-description · diff
git:20260808.51f4ff4 to git:20260809.d00d280
90 added, 0 removed. Audit C to A.
+ ---
+ name: git-pr-description
+ description: >
+ Формирует описание Pull Request из diff текущей ветки относительно базовой
+ (main/master). Анализирует все коммиты, выделяет «зачем / что / как проверить»,
+ фиксирует breaking changes. Используй, когда пользователь хочет «описать PR»,
+ «сделать описание для пуллреквеста», «оформить PR», «запушить и открыть PR»,
+ «сгенерируй PR description».
+ ---
+ # git-pr-description — Описание PR из diff ветки
+
+ Цель: дать пользователю готовое описание PR в один шаг — анализ коммитов и diff ветки против базовой ветки.
+
+ Перед началом прочитай `~/.claude/rules/git-conventions.md` — раздел про структуру PR.
+
+ ## Шаг 1. Определи базовую ветку и текущую
+
+ ```
+ git branch --show-current
+ git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@'
+ ```
+
+ Если `origin/HEAD` не определена — спроси пользователя: `main` или `master`. Запомни как `BASE`.
+
+ ## Шаг 2. Собери материал
+
+ ```
+ git log $BASE..HEAD --oneline
+ git log $BASE..HEAD --stat
+ git diff $BASE...HEAD --stat
+ git diff $BASE...HEAD
+ ```
+
+ Изучи, что менялось: список файлов, размер изменений, тексты коммитов.
+
+ ## Шаг 3. Сформируй заголовок PR
+
+ Заголовок — Conventional Commit для предполагаемого merge-коммита:
+ - если все коммиты ветки `feat` — `feat(<scope>): <общая фича>`
+ - если только `fix` — `fix(<scope>): <что починили>`
+ - если разные — выбери доминирующий type
+
+ ## Шаг 4. Сформируй описание
+
+ Структура (markdown):
+
+ ```markdown
+ ## Зачем
+
+ <1-2 предложения: какая проблема решается, чья боль, ссылки на issue/тикет>
+
+ ## Что изменилось
+
+ - <буллет по логическому изменению, не по файлу>
+ - <ещё один>
+ - <ещё>
+
+ ## Как проверить
+
+ <либо шаги для ручной проверки, либо «покрыто новыми тестами в X», либо «smoke в стейджинге»>
+
+ ## Риски / breaking changes
+
+ <либо «нет», либо явный список с миграцией>
+
+ Closes #N
+ ```
+
+ ## Шаг 5. Покажи и спроси
+
+ Покажи заголовок и описание в блоке. Спроси:
+ 1. Принять
+ 2. Поправить (что именно)
+ 3. Добавить чего-то (тесты, screenshots, migration plan)
+
+ ## Шаг 6. Опубликуй (опционально)
+
+ Если пользователь подтвердил и хочет открыть PR прямо сейчас:
+ - проверь, есть ли `gh` CLI: `which gh`
+ - если есть — `gh pr create --title "..." --body-file <tmp>` с подготовленным телом
+ - если нет — скажи, что нужно либо `gh` поставить, либо открыть PR через UI и вставить описание
+
+ **Не пушь ветку самостоятельно**, если она ещё не запушена. Покажи пользователю команду `git push -u origin <branch>` и дай ему решить.
+
+ ## Чего не делать
+
+ - Не дублируй subject коммита в «Что изменилось» — это не log, это саммари
+ - Не пиши «Что изменилось: добавил X, удалил Y, обновил Z» — это видно из diff. Пиши на уровне причин.
+ - Не выдумывай тестовые сценарии — если не уверен, как проверить, спроси
+ - Не клейми пользователя за плохие коммиты — просто аккуратно сложи их в описание