opencode-config/.opencode/skills/issue/SKILL.md

name	description
issue	Создаёт GitHub issue. Issue должны быть самодостаточными — агент в пустом чате может выполнить без доп. контекста. Если задача большая — разбей на несколько маленьких. Используй subagent для создания чтобы не засорять контекст. Also when user says "создай ишью", "создай issue", "заведи задачу", "разбей на подзадачи", "create issue".

Принцип: один issue = один PR

Issue — это атомарная задача, выполнимая за один PR. Если задача касается > 3-5 файлов или содержит независимые изменения → разбей на несколько issue. Каждый под-issue связывается с родительским через Part of #N. Родительский issue закрывается только когда все под-issue смержены.

Самодостаточность issue

Issue должно содержать всё необходимое, чтобы агент в пустом чате (без контекста предыдущей беседы) мог выполнить задачу:

• Пути к файлам — конкретные, с номерами строк если применимо (например src/video_uniq/effects/camera.py:72)
• Что менять — точное описание изменений, не абстрактное «улучшить» или «починить»
• Примеры из кода — если нужно показать паттерн, сослаться на конкретный файл и строки
• Команды проверки — какие команды запустить после изменений (pytest, ruff, mypy) и какой ожидаемый результат
• Связанные ресурсы — ссылки на связанные issue/PR (например Ref #33, Closes #33)

Структура body

## Контекст
(зачем это нужно, какая проблема решается)

## Что сделать
(пошагово, с путями к файлам)

### Шаг 1: ...
- Файл: `path/to/file.py`
- Изменить: ...

### Шаг 2: ...

## Проверка
(команды и ожидаемый результат)
- `pytest tests/test_xxx.py -x -q --no-cov` → all passed
- `ruff check path/to/file.py` → All checks passed
- `mypy path/to/file.py` → no issues

## Связанные ресурсы
- Ref #33
- [PR #34](https://github.com/...)

Правило дробления

Перед созданием issue оцени объём:

• 1-3 файлов → один issue

• 3-5 файлов или несколько независимых изменений → предложи пользователю разбить на несколько issue

• Каждый под-issue самодостаточен (свой контекст, свои пути, своя проверка)
• Связь через Part of #N (подзадача) и Closes #N (когда подзадача закрывает родительскую)

Пример:

Пользователь: «Перепиши логику рендеринга, добавь кэширование и почини баг с памятью» Агент: «Это 3 независимые задачи. Создам 3 issue: #10 (рендеринг), #11 (кэширование), #12 (баг памяти). Каждый выполним одним PR.»

Использование subagent для создания issue

Когда получает задачу создать issue:

1. Загрузи навык issue
2. Собери контекст (прочитай файлы, пойми задачу)
3. Запусти subagent для выполнения gh issue create — передай ему готовый title и body
4. Subagent создаёт issue и возвращает URL
5. Сообщи URL пользователю

Это нужно чтобы длинный body issue не засорял контекст основного агента.

Пример хорошего issue

## Контекст
Zoom breathing падает при включённом geometry crop — crop использует probe.width вместо iw.

## Что сделать
### Шаг 1: Заменить probe dimensions на iw/ih выражения
- Файл: `src/video_uniq/effects/camera.py:72`
- Заменить `w, h = probe.width, probe.height` на `iw`/`ih` выражения

## Проверка
- `pytest tests/test_effects.py -x -q --no-cov` → all passed
- `pytest tests/test_new_effects_real.py::test_geometry_crop_with_zoom_breathing_real` → passed

## Связанные ресурсы
- Closes #33

Пример плохого issue

**Зачем:** нужно улучшить обработку видео
**Что сделать:** переписать эффекты чтобы не падали

Почему плохо: нет путей к файлам, нет конкретных шагов, нет команд проверки, абстрактное описание.

Команда создания

gh issue create \
  --title "type(scope): description" \
  --body "..." \
  --label "enhancement"

Пути навыков

Навыки создаются в config/skills/ в репозитории opencode. НЕ в ~/.config/opencode/skills/ — это маунт из репо. После изменения навыка нужен git pull на хосте + рестарт контейнера.

Полный workflow

После создания issue, цикл продолжается:

1. Subagent — task(general) читает issue, реализует, коммитит, push, создаёт PR. Оркестрация — через pipeline-driver skill.
2. Review — @reviewer subagent ревьюит PR (diff, skills, standards), постит комментарий
3. Merge or Repeat — APPROVE → squash merge; замечания → fix subagent → re-review → merge

См. pipeline-driver skill для деталей PR процесса.