a8f9aa0bc6
* feat: migrate .opencode/ config from opencode * refactor: rename repo refs and sanitize for public * docs(handoff): add pr-7 handoff + ADR-002 * docs(handoff): fix PR number * docs: update project map with .opencode/ structure --------- Co-authored-by: opencode-agent <agent@slaid098.dev>
121 lines
No EOL
6.4 KiB
Markdown
121 lines
No EOL
6.4 KiB
Markdown
---
|
||
name: issue
|
||
description: Создаёт 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
|
||
|
||
```markdown
|
||
## Контекст
|
||
(зачем это нужно, какая проблема решается)
|
||
|
||
## Что сделать
|
||
(пошагово, с путями к файлам)
|
||
|
||
### Шаг 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
|
||
|
||
```markdown
|
||
## Контекст
|
||
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
|
||
|
||
```markdown
|
||
**Зачем:** нужно улучшить обработку видео
|
||
**Что сделать:** переписать эффекты чтобы не падали
|
||
```
|
||
|
||
Почему плохо: нет путей к файлам, нет конкретных шагов, нет команд проверки, абстрактное описание.
|
||
|
||
## Команда создания
|
||
|
||
```bash
|
||
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 процесса. |