codex-issue-digest

Codex Issue Digest

Objetivo

Produzir um resumo orientado a insights e com título em destaque das issues do openai/codex para os rótulos de área de funcionalidade solicitados, abrangendo as últimas 24 horas por padrão. Respeite uma duração diferente quando o usuário solicitar, por exemplo "semana passada" ou "48 horas". Padrão: resposta apenas com resumo; inclua detalhes apenas quando solicitado.

Inclua apenas issues que atualmente possuam bug ou enhancement e pelo menos um rótulo de proprietário solicitado. Se o usuário pedir todas as áreas ou todos os rótulos, colete issues bug/enhancement em todos os rótulos.

Entradas

• Rótulos de área de funcionalidade, por exemplo tui exec
• todas as áreas / todos os rótulos para examinar todos os rótulos de funcionalidade atuais
• Sobrescrita opcional de repositório, padrão openai/codex
• Janela de tempo opcional, padrão últimas 24 horas; exemplos: 48h, 7d, 1w, semana passada

Fluxo de Trabalho

1. Execute o coletor a partir de um checkout atual do repositório Codex:

python3 .codex/skills/codex-issue-digest/scripts/collect_issue_digest.py --labels tui exec --window-hours 24

Use --window "semana passada" ou --window-hours 168 quando o usuário solicitar uma duração não padrão. Use --all-labels quando o usuário disser todas as áreas ou todos os rótulos.

2. Use o JSON como fonte da verdade. Ele inclui novas issues, novos comentários de issues, novas reações/upvotes, rótulos atuais, contagens de reações atuais, summary_inputs prontos para modelo e digest_rows detalhados.
3. Escolha o modo de saída com base na solicitação do usuário:
   • Modo padrão: inicie o relatório com ## Resumo e não emita ## Detalhes.
   • Modo com detalhes antecipados: se o usuário pedir detalhes, uma tabela, um resumo completo, "incluir detalhes" ou similar, comece com ## Resumo e depois inclua ## Detalhes.
   • Modo de detalhes complementares: se o usuário pedir mais detalhes após um resumo apenas com resumo, produza ## Detalhes a partir do JSON do coletor existente quando ainda estiver disponível; caso contrário, execute o coletor novamente.
4. Em ## Resumo, escreva um resumo executivo com título em destaque:
   • A primeira linha não vazia abaixo de ## Resumo deve ser um título ou julgamento em linha única, não um marcador. Deve ser útil mesmo que o leitor pare ali.
   • Em dias calmos, prefira exatamente: Nenhuma issue importante relatada por usuários. Use isso quando não houver linhas elevadas, nenhum tema repetido recém-surgido e nada que exija ação do proprietário.
   • Quando os usuários estiverem destacando issues notáveis, faça o título mencionar a contagem ou tema, por exemplo Duas issues estão sendo destacadas por usuários:.
   • Imediatamente abaixo de um título ativo, liste apenas as issues ou temas que estão gerando atenção, ordenados por importância. Comece cada linha com o attention_marker da linha quando presente, depois uma descrição concisa legível pelo proprietário e referências inline das issues.
   • Trate 🔥🔥 como digno de título e 🔥 como elevado. Não adicione emoji de fogo você mesmo; apenas copie o attention_marker da linha.
   • Mantenha qualquer detalhe adicional do resumo após o título em 1-3 linhas concisas, apenas quando adicionar uma ressalva relevante para decisão, tema repetido ou ação do proprietário.
   • Não inclua contagens de rotina, estatísticas amplas ou resumos de tabela de baixo sinal em ## Resumo, a menos que mudem o título. Coloque metadados e contagens opcionais em ## Detalhes ou no rodapé.
   • No modo padrão, termine o relatório com um prompt conciso como Quer detalhes? Posso expandir isso para a tabela de issues. Mantenha isso separado do título do resumo para que o título permaneça limpo.
   • Agrupe e nomeie temas você mesmo a partir de summary_inputs; o coletor intencionalmente não codifica categorias de issues.
   • Use um agrupamento apenas quando as issues compartilharem genuinamente o mesmo problema de produto. Se várias issues apenas compartilharem uma plataforma ou rótulo amplo, descreva-as individualmente.
   • Não omita um tema repetido apenas porque suas issues individuais ficam abaixo do corte da tabela de detalhes. Vários relatórios semelhantes devem ser mencionados como uma preocupação repetida do cliente.
   • Para linhas de issue única, resuma a preocupação diretamente em vez de chamá-la de agrupamento.
   • Use links de issues numerados inline de ref_markdown de cada linha relevante.
   • Exemplo de resumo calmo:

## Resumo
Nenhuma issue importante relatada por usuários.

Fonte: coletor v5, git `abc123def456`, janela `2026-04-27T00:00:00Z` a `2026-04-28T00:00:00Z`.
Quer detalhes? Posso expandir isso para a tabela de issues.

• Exemplo de resumo ativo:

## Resumo
Duas issues estão sendo destacadas por usuários:
🔥🔥 Travamento do terminal na inicialização [1](https://github.com/openai/codex/issues/123)
🔥 Retomar alterna provedores de modelo inesperadamente [2](https://github.com/openai/codex/issues/456)

Fonte: coletor v5, git `abc123def456`, janela `2026-04-27T00:00:00Z` a `2026-04-28T00:00:00Z`.
Quer detalhes? Posso expandir isso para a tabela de issues.

5. Em ## Detalhes, quando detalhes forem solicitados, inclua uma tabela compacta apenas quando útil:
   • Prefira linhas de digest_rows; inclua uma coluna Refs usando ref_markdown de cada linha.
   • Mantenha a tabela curta; omita linhas de baixo sinal quando o resumo já as cobrir.
   • Use colunas compactas como marcador, área, tipo, descrição, interações e refs.
   • A célula Descrição deve ser uma frase curta legível pelo proprietário. Use a descrição da linha, título, trechos do corpo e comentários recentes, mas não copie mecanicamente o título bruto da issue do GitHub quando contiver detalhes incidentais.
   • Uma frase clara de calma/sem preocupação quando não houver sinal significativo.
6. Use o attention_marker do JSON exatamente. Está vazio para linhas normais, 🔥 para linhas elevadas e 🔥🔥 para linhas de atenção muito alta. Os cortes reais estão em attention_thresholds.
7. Use referências numeradas inline onde uma linha ou marcador aponta para issues, por exemplo Bugs de compactação [1](https://github.com/openai/codex/issues/123), [2](https://github.com/openai/codex/issues/456). Não adicione uma seção separada de notas de rodapé.
8. Rotule interactions como Interações; conta usuários humanos únicos do GitHub que criaram uma nova issue, adicionaram um novo comentário ou reagiram durante a janela solicitada. Múltiplas postagens/reações do mesmo usuário na mesma issue contam uma vez.
9. Mencione o script_version do coletor, o git_head do checkout do repositório e a janela de tempo em uma linha de fonte compacta. No modo padrão, coloque isso antes do prompt de detalhes para que a linha final ainda pergunte se o usuário quer detalhes. No modo com detalhes antecipados, pode ser o rodapé.

Tratamento de Reações

O coletor usa endpoints de reações do GitHub, que incluem created_at, para contar reações criadas durante a janela do resumo para issues hidratadas. Ele relata tanto as contagens de reações na janela quanto os totais de reações atuais. Trate os totais de reações atuais como engajamento permanente e trate new_reactions / new_upvotes como atividade na janela.

Por padrão, o coletor busca comentários de issues com since=<início da janela> e limita o número de páginas de comentários por issue. Isso evita que threads históricas muito longas dominem uma execução do resumo e foca o relatório em postagens recentes. Use --fetch-all-comments apenas quando o histórico exaustivo de comentários for mais importante que o tempo de execução.

A busca de issues do GitHub ainda é semeada pelo updated_at da issue, portanto uma issue puramente baseada em reações pode ser perdida se as reações não alterarem o updated_at. Cobrir todos os casos apenas de reações exigiria um armazenamento de instantâneo persistente ou uma varredura mais ampla de issues rotuladas.

Marcadores de Atenção

O coletor dimensiona os marcadores de atenção pela janela de tempo solicitada. A linha de base é 5 usuários humanos únicos para 🔥 e 10 usuários humanos únicos para 🔥🔥 em 24 horas; janelas mais longas ou mais curtas dimensionam esses cortes linearmente e arredondam para cima. Por exemplo, um relatório de uma semana usa 35 e 70 interações. Usuários humanos únicos são usuários que criaram uma nova issue, criaram um novo comentário ou reagiram durante a janela, incluindo upvotes. Múltiplas ações do mesmo usuário na mesma issue contam uma vez. Postagens de bots e reações de bots são excluídas. Em prosa, explique isso como alta interação do usuário em vez de nomear o emoji.

Atualização

A automação deve ser executada a partir de um checkout do repositório que contenha esta skill. Para uso diário compartilhado, prefira um destes padrões:

• Execute a automação em um checkout que seja atualizado antes do início da automação, por exemplo com git pull --ff-only.
• Se a automação não puder alterar o checkout com segurança, faça com que ela reporte o git_head atual da saída do coletor para que os leitores saibam qual versão da skill/script produziu o resumo.

Exemplo de Prompt do Proprietário

Use $codex-issue-digest para executar o resumo de issues do Codex para os rótulos tui e exec nas últimas 24 horas.

Use $codex-issue-digest para executar o resumo de issues do Codex para todas as áreas na última semana.

Validação

Execute em seco o coletor contra issues recentes:

python3 .codex/skills/codex-issue-digest/scripts/collect_issue_digest.py --labels tui exec --window-hours 24

python3 .codex/skills/codex-issue-digest/scripts/collect_issue_digest.py --all-labels --window "semana passada" --limit-issues 10

Execute os testes focados do script:

pytest .codex/skills/codex-issue-digest/scripts/test_collect_issue_digest.py