ship

name: ship description: | Полностью автоматизированный воркфлоу релиза: синхронизация с базовой веткой, запуск тестов, ревью diff, обновление CHANGELOG, коммит, пуш, создание PR. Для готовой к мержу ветки — не для планирования что строить.

Ship: Автоматизированный релиз

Release Prep Dependency

Перед автоматизированным ship сначала получить актуальный release-prep артефакт для той же ветки/релизного scope. Если release-prep даёт no-go, автоматический релиз не выполнять.

Ты выполняешь /ship. Это неинтерактивный, полностью автоматизированный воркфлоу. НЕ спрашивай подтверждения на каждом шаге. Пользователь сказал /ship — значит ДЕЛАТЬ. Двигайся сквозь и выведи URL пул-реквеста в конце.

Останавливаться только при:

• Ты на базовой ветке (прервать)
• Конфликты мержа которые нельзя авторазрешить (стоп, показать конфликты)
• Падение тестов (стоп, показать падения)
• Ревью находит проблемы требующие решения пользователя
• Нужен MINOR или MAJOR бамп версии (спросить)

Никогда не останавливаться при:

• Незакоммиченных изменениях (всегда включать их)
• Выборе бампа версии (авто-выбирать PATCH)
• Содержании CHANGELOG (авто-генерировать из diff)
• Одобрении сообщения коммита (авто-коммит)

Шаг 0: Определить базовую ветку

1. gh pr view --json baseRefName -q .baseRefName — если успешно, использовать.
2. gh repo view --json defaultBranchRef -q .defaultBranchRef.name — если PR нет.
3. Fallback: main.

Шаг 1: Предполётная проверка

1. Проверь текущую ветку: git branch --show-current

   • Если на базовой ветке → Прервать: "Ты на базовой ветке. Релизь из фиче-ветки."

2. git status — незакоммиченные изменения включаются автоматически, не спрашивать.

3. Понять что шипуется:

   git fetch origin <база> --quiet
   git diff origin/<база>...HEAD --stat
   git log origin/<база>..HEAD --oneline
   

Шаг 2: Синхронизация с базовой веткой

1. Смержи последнюю базовую ветку:

   git fetch origin <база>
   git merge origin/<база> --no-edit
   

2. Если конфликты мержа — СТОП. Показать конфликтующие файлы, попросить пользователя разрешить.

Шаг 3: Запуск тестов

Определи как запускаются тесты (проверь package.json, Makefile, pyproject.toml, pytest.ini):

# Python
python -m pytest 2>&1 | tail -20

# Node/Bun
bun test 2>&1 | tail -20

# Или из Makefile
make test 2>&1 | tail -20

Если тесты падают — СТОП. Вывести падения. Не двигаться дальше.

Шаг 4: Быстрое ревью diff

Проведи быстрый проход по diff (как /pr-review но только AUTO-FIX элементы):

git diff origin/<база>

Автоматически исправить:

• Мёртвый код
• Закомментированный код
• Очевидные проблемы консистентности

Для любого ASK-элемента (гонки, SQL-проблемы, нарушения доверия LLM) — СТОП и спроси пользователя.

Шаг 5: Обновление CHANGELOG

1. Прочитай текущий CHANGELOG.md (если существует).

2. Автогенерируй запись из diff и git log:

   git log origin/<база>..HEAD --oneline --no-merges
   

3. Формат записи CHANGELOG (для пользователей, не для контрибьюторов):

   • Веди с тем, что пользователь теперь может делать (а не что было изменено)
   • Простой язык: "Теперь можно..." вместо "Отрефакторено..."
   • Каждая запись должна заставить думать "о, хочу попробовать это"

4. Создай или обнови файл CHANGELOG.md с новой записью вверху.

Шаг 6: Бамп версии

Проверь файлы версий (VERSION, package.json, pyproject.toml, setup.py):

Автоматически выбирать PATCH для:

• Багфиксы
• Небольшие улучшения
• Обновления документации

СПРАШИВАТЬ для:

• Новые фичи не ломающие API → MINOR
• Breaking changes → MAJOR

Если найден файл с версией — обнови его.

Шаг 7: Коммит и пуш

Применить общие правила коммитов.

1. Собери все изменения:

   git add -A
   git status
   

2. Создай коммит с русскоязычным сообщением в формате <тип>: <описание>:

   git commit -m "$(cat <<'EOF'
   {краткое описание изменений}
   
   {детали если нужны — что и почему}
   EOF
   )"
   

3. Пуш:

   git push origin HEAD
   

Шаг 8: Создать PR

gh pr create \
  --title "{краткое описание <= 70 символов}" \
  --body "$(cat <<'EOF'
## Изменения
- {bullet 1}
- {bullet 2}

## Как тестировать
- [ ] {шаг 1}
- [ ] {шаг 2}

## Связанные TODO
{если есть}
EOF
)"

Вывести URL пул-реквеста.

Кросс-референс TODOS.md

После создания PR прочитай TODOS.md:

• Закрывает ли этот PR открытые TODO? Если да — отметить их как выполненные.
• Создаёт ли работу для нового TODO? Если да — спросить пользователя:
  • A) Добавить в TODOS.md
  • B) Пропустить

Итоговый вывод

✓ Тесты прошли
✓ Авто-исправлено N проблем
✓ CHANGELOG обновлён
✓ Версия: X.Y.Z → X.Y.Z+1
✓ Запушено и создан PR

PR: {URL}