agentleFS
Sign inStart free
jtprogrujtprogru/bear-skills/skills/git-pr-description/SKILL.md

git-pr-description

Skill1 starsChanged 3 months agoMITView on GitHub

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

  • Commits and pushes

The file

Create a free account to mount
Files
SKILL.md
<!-- СГЕНЕРИРОВАНО 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):

## Зачем

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free