# Git Pr Description

> Формирует описание Pull Request из diff текущей ветки относительно базовой (main/master). Анализирует все коммиты, выделяет «зачем / что / как проверить», фиксирует breaking changes. Используй, когда пользователь хочет «описать PR», «сделать описание для пуллреквеста», «оформить PR», «запушить и открыть PR», «сгенерируй PR description».

- Skill: `jtprogru/git-pr-description` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jtprogru/git-pr-description`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jtprogru/git-pr-description/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jtprogru (https://skillmd.com/u/jtprogru)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jtprogru/git-pr-description

---


<!-- СГЕНЕРИРОВАНО bin/mirror.js. Не редактировать: правки затрёт следующая генерация.
     Источник правды — domains/<домен>/. -->

# git-pr-description — Описание PR из diff ветки

Цель: дать пользователю готовое описание PR в один шаг — анализ коммитов и diff ветки против базовой ветки.

Перед началом прочитай `../../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. Пиши на уровне причин.
- Не выдумывай тестовые сценарии — если не уверен, как проверить, спроси
- Не клейми пользователя за плохие коммиты — просто аккуратно сложи их в описание