На карте
GitHub Issues хранит задачи рядом с файлами проекта. В карточке можно описать ошибку или нужное изменение, обсудить детали и сохранить подтверждение результата. Это помогает, когда работа растягивается на несколько дней или её выполняет другой человек либо ИИ-агент.
Разберём, какую информацию положить в задачу, как связать её с изменением файлов и когда закрывать. Понадобятся аккаунт GitHub и доступ к репозиторию, где включён раздел Issues. Программировать для этого не обязательно.
Порядок действий сверён с документацией GitHub 3 октября 2026 года. Создание и закрытие задач в аккаунте при подготовке не выполнялись.
Что находится в карточке задачи
Отдельная карточка называется issue. У неё есть заголовок, описание, номер, адрес и обсуждение. Номер имеет смысл внутри конкретного репозитория: задача #12 в двух проектах — две разные задачи.
Репозиторий хранит файлы и их историю. Issue описывает работу с ними, но сама файлы не меняет. Для предложения конкретной правки используют Pull Request, то есть запрос на включение изменений из другой ветки. А Projects помогает увидеть несколько задач на общей доске.
| Элемент | Что в нём фиксировать |
| Заголовок | Одно конкретное изменение или наблюдаемую проблему |
| Описание | Контекст, нужный результат и способ проверки |
| Комментарии | Уточнения, решения и результат выполнения |
| Labels — метки | Тип или направление работы по правилам проекта |
| Assignees — исполнители | Кто отвечает за работу |
Назначение исполнителя и установка меток зависят от прав. Для первого обращения достаточно понятного заголовка и описания; остальные поля не заменят постановку задачи. Создание issue и права участников.
Сначала найдите, не обсуждалась ли задача раньше
Откройте нужный репозиторий и вкладку Issues. Сверьте владельца и название проекта. Посмотрите открытые и закрытые карточки по ключевым словам: возможно, решение уже есть или работа ведётся.
Для сообщения об ошибке прочитайте README и CONTRIBUTING.md, если он существует: автор может просить использовать форму, другую площадку или определённый набор сведений. Если раздел Issues отсутствует, найдите указанный в README канал помощи. В своём проекте администратор может включить Issues в Settings → General → Features.
Если похожая карточка найдена, добавьте к ней новые сведения, когда это допускают правила. Повтор имеет смысл только при другой проблеме, которую нельзя точно описать в существующей задаче.
Опишите изменение так, чтобы его можно было принять
Нажмите New issue. Выберите подходящую форму, а если разрешена пустая карточка — заполните её самостоятельно. Формы разных проектов отличаются: обязательные поля нужны их сопровождающим.
Представим, что команда хранит в репозитории шаблон встречи meeting-notes.md. В нём есть решения, но после разговора непонятно, кто сделает следующий шаг. Заголовок «Улучшить встречи» слишком широк. «Добавить действие, ответственного и срок в шаблон встречи» задаёт границу работы.
Описание может выглядеть так:
## Контекст
В meeting-notes.md есть раздел «Решения», но нет места для следующего действия.
## Что изменить
После решений добавить раздел «Следующий шаг».
В нём должны быть поля: действие, ответственный, срок.
Остальные разделы оставить.
## Как проверить
Открыть сохранённый файл и заполнить один пример.
Проверить порядок разделов и наличие всех трёх полей.Это пример постановки задачи, а не готовая карточка вашего проекта. Подставьте фактический файл и ожидаемое поведение. Для ссылки на проблемный фрагмент удобно использовать адрес файла или конкретного коммита: будущие изменения тогда не сотрут исходный контекст.
Для ошибки вместо пожелания укажите последовательность действий, ожидаемый и фактический результат, версию программы и сообщение об ошибке. Например: «В README нажимаю “Шаблон заметок”; ожидаю meeting-notes.md, открывается отсутствующий notes.md». Такой текст даёт исполнителю воспроизводимый случай.
Откройте Preview, проверьте ссылки и содержание, затем нажмите Submit new issue. Сохраните адрес созданной карточки. Результат этого шага — зафиксированная задача; выполненной она ещё не стала.
Как вести работу, не теряя контекст
Уточнения пишите в карточке: какие файлы затронуты, что решили и какая часть остаётся неизвестной. Ссылки на обсуждения полезнее пересказа по памяти.
Если работу делает коллега или агент, описание должно объяснять исходное состояние, границы изменений и приёмку. «Починить всё» не даёт ни понятного объёма, ни способа проверить результат. Обнаруженную по ходу другую проблему обычно стоит выделить в отдельную задачу со ссылкой на исходную.
Исполнитель меняет файлы по процедуре проекта. В общем репозитории это часто отдельная ветка и Pull Request. Приложите к issue ссылку на PR: по ней можно увидеть, какие строки предлагают изменить и что осталось на проверке.
В описании PR можно написать Closes #12, заменив номер реальной задачей этого репозитория. GitHub связывает такой запрос с issue и закрывает её при слиянии в основную ветку по правилам этого механизма. Для PR в другую ветку ключевые слова работают иначе: автоматического закрытия ожидать не следует. Связь PR и issue.
Обычное упоминание #12 сохраняет ссылку в обсуждении, но само по себе не означает, что работа завершена.
Когда закрывать задачу
Сравните результат с критериями из описания. Для шаблона встречи это чтение итогового файла в нужной ветке и проверка трёх полей. Для ошибки программы — повтор исходных шагов на исправленной версии.
В комментарии укажите, что фактически проверили, и дайте ссылку на файл, коммит или запуск проверки. «Готово» без этого оставляет следующему читателю весь разбор заново.
Затем закройте issue, если есть права и результат соответствует задаче. Различайте завершённую работу и отказ от неё: доступная причина закрытия должна отражать решение. Если критерии не выполнены, оставьте задачу открытой и опишите расхождение. Автоматическое закрытие после merge тоже стоит сверить с реальным результатом, особенно если публикация или выпуск программы происходят отдельно.
Полезные сценарии
Передать небольшую работу другому человеку. У вас есть конкретный документ и понятный пробел. Укажите файл, желаемую правку и критерии; после выполнения проверьте итог и приложите подтверждение. Получится задача с прослеживаемым результатом. Назначение исполнителя не гарантирует срок: его нужно согласовать отдельно.
Сообщить автору программы об ошибке. Проблема воспроизводится на известной версии. Найдите прошлые обращения, заполните принятую форму и добавьте минимальные шаги воспроизведения. Автор получает случай, который может проверить. Не помещайте в логи токены, данные клиентов и другую закрытую информацию; для сообщения об уязвимости используйте указанный проектом частный канал.
Вернуться к незавершённой идее. Зафиксируйте полезное изменение, но явно напишите, что ещё нужно решить до начала работы. По карточке восстановите контекст и уточните критерии перед выполнением. Если нужен широкий выбор подхода, сначала удобнее обсуждение, а не задача с выдуманным решением.
Если карточка не приводит к результату
| Ситуация | Что уточнить |
| Исполнитель не понимает, что делать | Файл, исходное поведение и ожидаемый результат |
| Работа завершена, но проверить её невозможно | Версию, ссылку и шаги проверки |
| Задача закрылась, а сайт не изменился | Что именно включено в основную ветку и как выпускается сайт |
| Нет кнопки редактирования или закрытия | Аккаунт, права и правила проекта |
| Проблема появилась снова | Новые шаги воспроизведения; возможность открыть карточку заново |
Начните с одного изменения, которое сможете проверить. Хорошая issue хранит не только просьбу, но и ответ на вопрос, чем закончилась работа.
Следующий шаг
Когда задач станет несколько, соберите их на общей доске: GitHub Projects — управление задачами AI-агентов.
Если вы передаёте работу коллегам или ИИ-агентам, начните с одной задачи и проверьте, хватает ли её описания для самостоятельного выполнения.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov.
