codex-issue-digest

Codex Issue Digest — навык для дайджеста GitHub issues репозитория openai/codex. По умолчанию он собирает headline-first сводку за предыдущие 24 часа, но принимает другой интервал, например 48 часов, неделю или 7 дней. Область можно ограничить feature-area labels вроде tui, exec или app либо попросить all areas и all labels. В выборку попадают только issues с текущей меткой bug или enhancement и хотя бы одной запрошенной owner-меткой; при режиме всех областей собираются bug/enhancement issues среди текущих feature labels. Репозиторий можно переопределить, но стандартный — openai/codex. Сборщик запускается из актуального checkout Codex, например командой python3 .codex/skills/codex-issue-digest/scripts/collect_issue_digest.py --labels tui exec --window-hours 24. Для другого периода можно использовать параметр window past week или эквивалентное число часов, а для всех областей — all-labels. JSON коллектора является источником истины для отчёта: в нём есть новые issues, новые комментарии, новые реакции и upvotes, текущие labels и totals реакций, а также summary_inputs и digest_rows, подготовленные для модели. Сам факт запуска из checkout важен для воспроизводимости: в результате следует указать версию скрипта, git head и фактическое окно времени. Режим вывода по умолчанию — только summary. Под заголовком Summary первая непустая строка должна быть однострочным headline или суждением, которое понятно без чтения остального текста. Затем перечисляются только issues или темы, действительно формирующие внимание, в порядке важности, с inline numbered links из ref_markdown. Для тихого периода предпочтителен текст No major issues reported by users.; при активном сигнале headline должен назвать число или тему, например, что пользователи поднимают две проблемы. Детали, таблица и секция Details добавляются только если их запросили или если нужен полный дайджест. Рутинные общие счётчики не должны вытеснять decision-relevant вывод; в summary допустимы лишь краткие caveat, повторяющаяся тема или действие владельца. Тему можно кластеризовать только при настоящей общей продуктовой проблеме, а не из-за одной широкой label. Attention marker коллектора нужно копировать как есть: пустой для обычной строки, fire для повышенного внимания и double-fire для очень высокого. Добавлять marker самостоятельно нельзя. Маркеры масштабируются по окну: базовые пороги для 24 часов — пять уникальных людей для повышенного и десять для очень высокого внимания; при более длинном или коротком периоде пороги изменяются пропорционально с округлением вверх. Под interactions понимаются уникальные люди, которые создали issue, оставили новый комментарий или поставили реакцию в окне; несколько действий одного человека на одной issue считаются один раз. Боты и bot reactions исключаются. В тексте это следует описывать как высокое взаимодействие пользователей, не заменяя результат формальными эмодзи-выводами. Механика реакций различает активность в окне и текущую накопленную вовлечённость. Коллектор использует endpoint реакций с created_at, поэтому new_reactions и new_upvotes относятся к заданному периоду, а текущие reaction totals являются standing engagement. Комментарии обычно запрашиваются с since начала окна и ограниченным числом страниц; fetch-all-comments предназначен для случаев, когда важнее исчерпывающая история, чем время выполнения. Поиск issues стартует через updated_at, поэтому issue только с новой реакцией может не попасть в результат, если реакция не меняет updated_at; полное покрытие таких случаев потребовало бы сохранённого snapshot store или более широкого обхода. Детали, если они нужны, строятся компактной таблицей из digest_rows с колонками marker, area, type, описание, interactions и refs. Описание должно быть понятным владельцу: допустимо использовать title, body excerpt и свежие комментарии, но не следует механически копировать заголовок с случайными деталями. Для follow-up с деталями можно использовать уже сохранённый JSON, пока он доступен; иначе collector запускается заново. В конце summary-only отчёта остаётся отдельный вопрос о раскрытии деталей, а не смешанный с headline. Перед ежедневным использованием checkout желательно обновить безопасным способом; если это невозможно, нужно сообщить текущий git head. Проверяемый базовый режим включает запуск коллектора для tui и exec за 24 часа, а focused script tests лежат рядом с collect_issue_digest.py и запускаются через pytest.