Коммит и pull request одним шагом

За один проход добавляет изменения в индекс, коммитит, отправляет ветку и открывает черновой pull request на GitHub.

СкиллOpenAICodexApache-2.0Нужен терминалПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: За один проход добавляет изменения в индекс, коммитит, отправляет ветку и открывает черновой pull request на GitHub.
Когда брать: Когда пользователь прямо просит закоммитить, отправить изменения и открыть pull request на GitHub.
Когда не брать: Если не просили сразу отправлять изменения и открывать pull request или не установлен GitHub CLI.
Пример запроса: Закоммить всё, отправь ветку и открой черновой pull request.
Нужно подключить: терминал, git, GitHub CLI (gh), аккаунт GitHub

Как включить

Скачайте архив и распакуйте его.
Положите папку yeet в ~/.agents/skills/.
Вызовите скилл командой $yeet или найдите его через /skills.

Текст

---
name: "yeet"
description: "Используй, только если пользователь прямо просит за один проход добавить изменения в индекс, закоммитить, отправить и открыть pull request на GitHub с помощью GitHub CLI (`gh`)."
---

Предварительные условия

Требуется GitHub CLI gh. Проверь gh --version. Если его нет, попроси пользователя установить gh и остановись.
Требуется авторизованная сессия gh. Выполни gh auth status. Если авторизации нет, попроси пользователя выполнить gh auth login (и повторить gh auth status), прежде чем продолжать.

Соглашения об именовании

Ветка: {description}, когда начинаешь с main/master/ветки по умолчанию.
Коммит: {description} (кратко).
Заголовок PR: {description}, суммирующее весь diff.

Поиск шаблона PR

Перед созданием PR определи корень репозитория и поищи от него действующий шаблон PR для GitHub:

repo_root="$(git rev-parse --show-toplevel)"

Кандидаты на шаблон, по порядку:

.github/pull_request_template.md
.github/PULL_REQUEST_TEMPLATE.md
Один файл *.md в .github/pull_request_template/
Один файл *.md в .github/PULL_REQUEST_TEMPLATE/

Используй пути в том виде, как их выдаёт команда от корня репозитория, например .github/pull_request_template.md, а не ./.github/pull_request_template.md.

Если найден ровно один шаблон, прочитай его перед составлением итогового тела PR и передай в gh pr create через --template "$template".

Если найдено несколько файлов шаблонов, остановись перед созданием PR и спроси, какой шаблон использовать. Если шаблона нет, используй запасную форму тела из этого скилла.

Рабочий процесс

Если ты на main/master/ветке по умолчанию, создай ветку: git checkout -b "{description}"
Иначе остайся на текущей ветке.
Проверь состояние, затем добавь всё в индекс: git status -sb, затем git add -A.
Закоммить кратко с описанием: git commit -m "{description}"
Запусти проверки, если они ещё не запускались. Если проверки падают из-за отсутствующих зависимостей или инструментов, установи зависимости и перезапусти один раз.
Отправь с отслеживанием: git push -u origin $(git branch --show-current)
Если git push падает из-за ошибок авторизации рабочего процесса (workflow), подтяни изменения из master и повтори отправку.
Найди и прочитай шаблон PR репозитория, если он есть.
Проверь, есть ли уже PR у текущей ветки: gh pr view "$(git branch --show-current)" --json number,isDraft,url
Если PR уже существует, обнови этот PR на месте. Не создавай другой PR и не меняй статус существующего PR (черновик или готов к проверке).
Если PR нет, открой новый черновой PR:
С одним шаблоном: GH_PROMPT_DISABLED=1 GIT_TERMINAL_PROMPT=0 gh pr create --draft --fill --template "$template" --head "$(git branch --show-current)"
Без шаблона: GH_PROMPT_DISABLED=1 GIT_TERMINAL_PROMPT=0 gh pr create --draft --fill --head "$(git branch --show-current)"
Отредактируй заголовок и тело PR так, чтобы они отражали реальное итоговое изменение в diff.
Запиши описание PR во временный файл с настоящими переводами строк и передай его через --body-file или gh pr edit --body-file, чтобы в markdown не оказалось экранированных \n.

Определение PR

Когда обновляешь PR, созданный ранее в этом процессе, по возможности определи PR по текущей ветке:

git branch --show-current
gh pr view "$(git branch --show-current)" --json number --jq '.number'

Если так найден существующий PR, сохрани его текущее состояние проверки. Никогда не переводи существующий PR, готовый к проверке, обратно в черновик в рамках yeet; черновиками должны начинаться только новые PR, созданные этим процессом.

Заголовок PR

Формат: <type>(<scope>): <subject>

<scope> необязателен. Область (scope) — это существительное, описывающее часть кодовой базы (компонент, сервис или подсистему).

Пример

feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Краткое описание в настоящем времени.
|
+-------> Тип: chore, docs, feat, fix, refactor, style или test.

Другие примеры:

feat: (новая функция для пользователя, а не новая функция для скрипта сборки)
fix: (исправление ошибки для пользователя, а не исправление скрипта сборки)
docs: (изменения документации)
style: (форматирование, пропущенные точки с запятой и т. п.; код рабочей среды не меняется)
refactor: (рефакторинг кода рабочей среды, например переименование переменной)
test: (добавление недостающих тестов, рефакторинг тестов; код рабочей среды не меняется)
chore: (обновление задач grunt и т. п.; код рабочей среды не меняется)

Содержимое тела PR

Когда скилл вызван, используй gh, чтобы отредактировать тело и заголовок pull request так, чтобы они отражали содержимое указанного PR. Обязательно проверь существующее тело pull request: возможно, в нём есть ключевая информация, которую нужно сохранить. Например, НИКОГДА не удаляй изображение из существующего тела pull request, потому что у автора может не быть способа его восстановить.

Когда у репозитория есть шаблон PR, приведи итоговое тело PR в соответствие с ним. Сохраняй значимые заголовки, обязательные чек-листы и специфичные для репозитория подсказки, но заменяй текст-заполнитель содержимым, относящимся к итоговому изменению в diff, или N/A там, где шаблон этого просит. Не выбрасывай разделы шаблона только потому, что запасная форма ниже короче.

Критически важно объяснить, _зачем_ вносится изменение. Если в текущем разговоре, в котором вызван этот скилл, обсуждалась мотивация, обязательно отрази её в теле pull request.

Тело должно также объяснять, _что_ изменилось, но это должно идти после _зачем_.

Ограничивайся _итоговым изменением_ коммита. Обсуждать изменения, которые пробовали, но позже отменили в ходе разработки pull request, обычно не принято. Переписывая тело pull request, возможно, придётся убрать такие подробности, когда они перестали быть уместными или интересными будущим читателям.

Избегай ссылок на абсолютные пути на моём локальном диске. Говоря о пути внутри репозитория, просто используй путь относительно репозитория.

По умолчанию опускай Verification. Добавляй его, только когда у тебя есть подтверждение поведения, которое стоит сохранить для проверяющих: воспроизведённая ошибка, проверка «до и после», точечный тест, проверяющий изменённое поведение, или ручной сценарий с входными данными и наблюдаемым результатом. Не используй его для типовых команд и результатов автоматики, таких как тесты пакета, проверки типов, линтеры, форматировщики, хуки pre-commit/pre-push или статус CI.

Если шаблон репозитория требует раздел проверки или верификации, оставь этот раздел и избегай типового наполнителя: укажи содержательные команды и результаты, точечный ручной сценарий или Not run с причиной.

Используй аккуратный Markdown:

Код, пути, команды, флаги и идентификаторы заключай в обратные кавычки.
Для расшифровок оболочки и многострочных примеров используй блоки кода в ограждении.
Когда цитируешь существующий код, относящийся к изменению, используй постоянные ссылки GitHub (permalink).
Ссылайся на связанные задачи или PR, но не ссылайся на PR в его собственном теле.

Предлагаемая форма тела PR

Используй её как запасной вариант, когда у репозитория нет шаблона PR:

## Why

Опиши проблему для пользователей или мейнтейнеров, включая причину и следствие, где это полезно.

## What Changed

Опиши итоговое изменение реализации кратко и связным текстом.

Перевод: iiuniversitet. Оригинал: https://github.com/openai/skills/tree/main/skills/.curated/yeet, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
name: "yeet"
description: "Use only when the user explicitly asks to stage, commit, push, and open a GitHub pull request in one flow using the GitHub CLI (`gh`)."
---

## Prerequisites

- Require GitHub CLI `gh`. Check `gh --version`. If missing, ask the user to install `gh` and stop.
- Require authenticated `gh` session. Run `gh auth status`. If not authenticated, ask the user to run `gh auth login` (and re-run `gh auth status`) before continuing.

## Naming conventions

- Branch: `{description}` when starting from main/master/default.
- Commit: `{description}` (terse).
- PR title: `{description}` summarizing the full diff.

## PR template discovery

Before creating the PR, resolve the repository root and look for the active GitHub PR template from there:

```shell
repo_root="$(git rev-parse --show-toplevel)"
```

Template candidates, in order:

- `.github/pull_request_template.md`
- `.github/PULL_REQUEST_TEMPLATE.md`
- One `*.md` file under `.github/pull_request_template/`
- One `*.md` file under `.github/PULL_REQUEST_TEMPLATE/`

Use paths as emitted from the repository root, such as `.github/pull_request_template.md`, not `./.github/pull_request_template.md`.

If exactly one template is found, read it before composing the final PR body and pass it to `gh pr create` with `--template "$template"`.

If multiple template files are found, stop before PR creation and ask which template to use. If no template exists, use the fallback body shape in this skill.

## Workflow

- If on main/master/default, create a branch: `git checkout -b "{description}"`
- Otherwise stay on the current branch.
- Confirm status, then stage everything: `git status -sb` then `git add -A`.
- Commit tersely with the description: `git commit -m "{description}"`
- Run checks if not already. If checks fail due to missing deps/tools, install dependencies and rerun once.
- Push with tracking: `git push -u origin $(git branch --show-current)`
- If git push fails due to workflow auth errors, pull from master and retry the push.
- Discover and read the repository PR template, if any.
- Check whether the current branch already has a PR: `gh pr view "$(git branch --show-current)" --json number,isDraft,url`
- If a PR already exists, update that PR in place. Do not create another PR, and do not change whether the existing PR is draft or ready for review.
- If no PR exists, open a new draft PR:
- With one template: `GH_PROMPT_DISABLED=1 GIT_TERMINAL_PROMPT=0 gh pr create --draft --fill --template "$template" --head "$(git branch --show-current)"`
- Without a template: `GH_PROMPT_DISABLED=1 GIT_TERMINAL_PROMPT=0 gh pr create --draft --fill --head "$(git branch --show-current)"`
- Edit the PR title and body so they reflect the actual net change in the diff.
- Write the PR description to a temp file with real newlines and pass it via `--body-file` or `gh pr edit --body-file` to avoid `\n`-escaped markdown.

## Determining the PR

When updating a PR created earlier in the flow, infer the PR from the current branch when possible:

```shell
git branch --show-current
gh pr view "$(git branch --show-current)" --json number --jq '.number'
```

If this finds an existing PR, preserve its current review state. Never convert an existing ready-for-review PR back to draft as part of `yeet`; only new PRs created by this flow should start as draft.

## PR Title

Format: `<type>(<scope>): <subject>`

`<scope>` is optional. A scope consist of a noun describing a section of the codebase (component, service or subsytem).

### Example

```
feat: add hat wobble
^--^ ^------------^
| |
| +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.
```

More Examples:

- `feat`: (new feature for the user, not a new feature for build script)
- `fix`: (bug fix for the user, not a fix to a build script)
- `docs`: (changes to the documentation)
- `style`: (formatting, missing semi colons, etc; no production code change)
- `refactor`: (refactoring production code, eg. renaming a variable)
- `test`: (adding missing tests, refactoring tests; no production code change)
- `chore`: (updating grunt tasks etc; no production code change)

## PR Body Contents

When invoked, use `gh` to edit the pull request body and title to reflect the contents of the specified PR. Make sure to check the existing pull request body to see if there is key information that should be preserved. For example, NEVER remove an image in the existing pull request body, as the author may have no way to recover it if you remove it.

When a repository PR template exists, adapt the final PR body to that template. Preserve meaningful headings, required checklists, and repo-specific prompts, but replace placeholder text with net-diff-specific content or `N/A` where the template asks for it. Do not discard template sections just because the fallback shape below is shorter.

It is critically important to explain _why_ the change is being made. If the current conversation in which this skill is invoked has discussed the motivation, be sure to capture this in the pull request body.

The body should also explain _what_ changed, but this should appear after the _why_.

Limit discussion to the _net change_ of the commit. It is generally frowned upon to discuss changes that were attempted but later undone in the course of the development of the pull request. When rewriting the pull request body, you may need to eliminate details such as these when they are no longer appropriate / of interest to future readers.

Avoid references to absolute paths on my local disk. When talking about a path that is within the repository, simply use the repo-relative path.

Default to omitting `Verification`. Add it only when you have behavioral evidence worth preserving for reviewers: a reproduced bug, a before/after check, a targeted test that exercises the changed behavior, or a manual scenario with input and observed outcome. Do not use it for generic commands or automation results such as package tests, type checks, linters, formatters, pre-commit/pre-push hooks, or CI status.

If the repository template requires a validation or verification section, keep that section and avoid generic filler: include meaningful commands/results, a targeted manual scenario, or `Not run` with a reason.

Use professional Markdown:

- Put code, paths, commands, flags, and identifiers in backticks.
- Use fenced code blocks for shell transcripts or multi-line examples.
- Use GitHub permalinks when citing existing code relevant to the change.
- Reference relevant issues or related PRs, but do not reference the PR in its own body.

### Suggested PR Body Shape

Use this as a fallback when the repository does not have a PR template:

```markdown
## Why

Describe the user-facing or maintainer-facing problem, including cause and effect where useful.

## What Changed

Describe the net implementation change in concise prose.
```

Источник: openai/skills / yeet ↗. Ссылка проверена 2026-10-10.

---
name: "yeet"
description: "Используй, только если пользователь прямо просит за один проход добавить изменения в индекс, закоммитить, отправить и открыть pull request на GitHub с помощью GitHub CLI (`gh`)."
---

## Предварительные условия

- Требуется GitHub CLI `gh`. Проверь `gh --version`. Если его нет, попроси пользователя установить `gh` и остановись.
- Требуется авторизованная сессия `gh`. Выполни `gh auth status`. Если авторизации нет, попроси пользователя выполнить `gh auth login` (и повторить `gh auth status`), прежде чем продолжать.

## Соглашения об именовании

- Ветка: `{description}`, когда начинаешь с main/master/ветки по умолчанию.
- Коммит: `{description}` (кратко).
- Заголовок PR: `{description}`, суммирующее весь diff.

## Поиск шаблона PR

Перед созданием PR определи корень репозитория и поищи от него действующий шаблон PR для GitHub:

```shell
repo_root="$(git rev-parse --show-toplevel)"
```

Кандидаты на шаблон, по порядку:

- `.github/pull_request_template.md`
- `.github/PULL_REQUEST_TEMPLATE.md`
- Один файл `*.md` в `.github/pull_request_template/`
- Один файл `*.md` в `.github/PULL_REQUEST_TEMPLATE/`

Используй пути в том виде, как их выдаёт команда от корня репозитория, например `.github/pull_request_template.md`, а не `./.github/pull_request_template.md`.

Если найден ровно один шаблон, прочитай его перед составлением итогового тела PR и передай в `gh pr create` через `--template "$template"`.

Если найдено несколько файлов шаблонов, остановись перед созданием PR и спроси, какой шаблон использовать. Если шаблона нет, используй запасную форму тела из этого скилла.

## Рабочий процесс

- Если ты на main/master/ветке по умолчанию, создай ветку: `git checkout -b "{description}"`
- Иначе остайся на текущей ветке.
- Проверь состояние, затем добавь всё в индекс: `git status -sb`, затем `git add -A`.
- Закоммить кратко с описанием: `git commit -m "{description}"`
- Запусти проверки, если они ещё не запускались. Если проверки падают из-за отсутствующих зависимостей или инструментов, установи зависимости и перезапусти один раз.
- Отправь с отслеживанием: `git push -u origin $(git branch --show-current)`
- Если git push падает из-за ошибок авторизации рабочего процесса (workflow), подтяни изменения из master и повтори отправку.
- Найди и прочитай шаблон PR репозитория, если он есть.
- Проверь, есть ли уже PR у текущей ветки: `gh pr view "$(git branch --show-current)" --json number,isDraft,url`
- Если PR уже существует, обнови этот PR на месте. Не создавай другой PR и не меняй статус существующего PR (черновик или готов к проверке).
- Если PR нет, открой новый черновой PR:
  - С одним шаблоном: `GH_PROMPT_DISABLED=1 GIT_TERMINAL_PROMPT=0 gh pr create --draft --fill --template "$template" --head "$(git branch --show-current)"`
  - Без шаблона: `GH_PROMPT_DISABLED=1 GIT_TERMINAL_PROMPT=0 gh pr create --draft --fill --head "$(git branch --show-current)"`
- Отредактируй заголовок и тело PR так, чтобы они отражали реальное итоговое изменение в diff.
- Запиши описание PR во временный файл с настоящими переводами строк и передай его через `--body-file` или `gh pr edit --body-file`, чтобы в markdown не оказалось экранированных `\n`.

## Определение PR

Когда обновляешь PR, созданный ранее в этом процессе, по возможности определи PR по текущей ветке:

```shell
git branch --show-current
gh pr view "$(git branch --show-current)" --json number --jq '.number'
```

Если так найден существующий PR, сохрани его текущее состояние проверки. Никогда не переводи существующий PR, готовый к проверке, обратно в черновик в рамках `yeet`; черновиками должны начинаться только новые PR, созданные этим процессом.

## Заголовок PR

Формат: `<type>(<scope>): <subject>`

`<scope>` необязателен. Область (scope) — это существительное, описывающее часть кодовой базы (компонент, сервис или подсистему).

### Пример

```
feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Краткое описание в настоящем времени.
|
+-------> Тип: chore, docs, feat, fix, refactor, style или test.
```

Другие примеры:

- `feat`: (новая функция для пользователя, а не новая функция для скрипта сборки)
- `fix`: (исправление ошибки для пользователя, а не исправление скрипта сборки)
- `docs`: (изменения документации)
- `style`: (форматирование, пропущенные точки с запятой и т. п.; код рабочей среды не меняется)
- `refactor`: (рефакторинг кода рабочей среды, например переименование переменной)
- `test`: (добавление недостающих тестов, рефакторинг тестов; код рабочей среды не меняется)
- `chore`: (обновление задач grunt и т. п.; код рабочей среды не меняется)


## Содержимое тела PR

Когда скилл вызван, используй `gh`, чтобы отредактировать тело и заголовок pull request так, чтобы они отражали содержимое указанного PR. Обязательно проверь существующее тело pull request: возможно, в нём есть ключевая информация, которую нужно сохранить. Например, НИКОГДА не удаляй изображение из существующего тела pull request, потому что у автора может не быть способа его восстановить.

Когда у репозитория есть шаблон PR, приведи итоговое тело PR в соответствие с ним. Сохраняй значимые заголовки, обязательные чек-листы и специфичные для репозитория подсказки, но заменяй текст-заполнитель содержимым, относящимся к итоговому изменению в diff, или `N/A` там, где шаблон этого просит. Не выбрасывай разделы шаблона только потому, что запасная форма ниже короче.

Критически важно объяснить, _зачем_ вносится изменение. Если в текущем разговоре, в котором вызван этот скилл, обсуждалась мотивация, обязательно отрази её в теле pull request.

Тело должно также объяснять, _что_ изменилось, но это должно идти после _зачем_.

Ограничивайся _итоговым изменением_ коммита. Обсуждать изменения, которые пробовали, но позже отменили в ходе разработки pull request, обычно не принято. Переписывая тело pull request, возможно, придётся убрать такие подробности, когда они перестали быть уместными или интересными будущим читателям.

Избегай ссылок на абсолютные пути на моём локальном диске. Говоря о пути внутри репозитория, просто используй путь относительно репозитория.

По умолчанию опускай `Verification`. Добавляй его, только когда у тебя есть подтверждение поведения, которое стоит сохранить для проверяющих: воспроизведённая ошибка, проверка «до и после», точечный тест, проверяющий изменённое поведение, или ручной сценарий с входными данными и наблюдаемым результатом. Не используй его для типовых команд и результатов автоматики, таких как тесты пакета, проверки типов, линтеры, форматировщики, хуки pre-commit/pre-push или статус CI.

Если шаблон репозитория требует раздел проверки или верификации, оставь этот раздел и избегай типового наполнителя: укажи содержательные команды и результаты, точечный ручной сценарий или `Not run` с причиной.

Используй аккуратный Markdown:

- Код, пути, команды, флаги и идентификаторы заключай в обратные кавычки.
- Для расшифровок оболочки и многострочных примеров используй блоки кода в ограждении.
- Когда цитируешь существующий код, относящийся к изменению, используй постоянные ссылки GitHub (permalink).
- Ссылайся на связанные задачи или PR, но не ссылайся на PR в его собственном теле.

### Предлагаемая форма тела PR

Используй её как запасной вариант, когда у репозитория нет шаблона PR:

```markdown
## Why

Опиши проблему для пользователей или мейнтейнеров, включая причину и следствие, где это полезно.

## What Changed

Опиши итоговое изменение реализации кратко и связным текстом.
```

Перевод: iiuniversitet. Оригинал: https://github.com/openai/skills/tree/main/skills/.curated/yeet, лицензия Apache-2.0. Изменения: перевод на русский язык.