Артефакты GitHub Issues: постоянное место для планов и контекста
Код находится в pull request, а объяснение решения иногда теряется в старом чате. Если исследование агента хранится отдельно, следующий разработчик может повторить его. 28 октября GitHub представил публичную предварительную версию артефактов, прикрепляемых прямо к issue.
Обсуждение и обновляемый документ дополняют друг друга
Артефактом может быть Markdown, внешняя ссылка или HTML: анализ причин, прототип либо обсуждение в Slack и Teams. На github.com их можно создавать и редактировать с сохранением версий. Это не артефакты GitHub Actions, представляющие результаты запусков workflow.
Представим вымышленную ошибку двойной обработки платежа. Комментарии содержат новые наблюдения, а план — работу ключа повторной попытки и ещё не проведённые эксперименты. Первое изображение создано для статьи и не является экраном GitHub. Разделение фактов и гипотез помогает не превратить догадку в требование.

Прикрепить файл и поддерживать тот же контекст
gh issue artifact create принимает номер или URL issue, затем файлы либо ссылки. gh issue artifact create 42 retry-plan.md -R OWNER/REPO прикрепил бы файл к issue 42. Это условные значения; выполнение создаёт данные в задаче. Для статьи команда не запускалась.
Имя берётся из файла или задаётся через --name. --body-file читает содержимое одного документа, --attach поддерживает изображения и видео. gh issue artifact edit 42 1 --body-file retry-plan.md -R OWNER/REPO заменяет содержимое. Второе изображение показывает синтаксис, а не успешную загрузку.

Актуальный план не теряет историю
edit меняет имя или содержимое, но не тип. --restore-version сохраняет прежние имя и содержимое как новую версию; view показывает историю. Актуальность документа не требует стирать путь к решению.
В примере платежа подозрение может перейти с тайм-аута на обработку повторяющихся ключей. Обновить план и связать комментарий с объяснением — предложение по ведению документации, а не обещанное автоматическое действие. Сам документ не доказывает правильность кода.
Поддержка HTML зависит от интерфейса
В объявлении описано переключение между HTML-просмотром и исходником. Однако создание и просмотр HTML в GitHub App заявлены на будущее. Автоматическое прикрепление результатов сессии не означает полный HTML во всех интерфейсах. CLI тоже остаётся предварительной версией.
Польза — в расположении контекста рядом с работой, а не в числе документов. Достаточно существующего плана и следующего обновления, чтобы изучить процесс. Текущие возможности уточняются в официальных источниках.