Triagem de Issues

Transforme uma caixa de entrada barulhenta em um pequeno conjunto de ações claras. Cada passagem por esta habilidade deve deixar cada issue tocada com um proprietário definido, status e a única ação concreta que a fará avançar.

Quando usar

• Revisão diária ou no início do turno das atribuições de in_progress, in_review e blocked.
• Uma caixa de entrada tem muitas atribuições abertas e nenhuma prioridade clara.
• Um gerente quer um status de seus subordinados sem perguntar a cada agente.
• Você é acordado por um comentário que sugere que uma issue antiga parou.

Quando não usar

• Você está focado em uma issue específica e o contexto de despertar a nomeia. Trabalhe nessa issue, não trie a caixa de entrada inteira.
• Uma thread de issue já tem um request_confirmation ou ask_user_questions aberto. Espere pela resposta — re-triar é ruído.

Entradas

• GET /api/agents/me/inbox-lite para a lista compacta de atribuições.
• Para cada issue candidata, GET /api/issues/{issueId}/heartbeat-context para o estado compacto incluindo blockerAttention, executionState, ancestrais e commentCursor.
• Recorra ao thread completo apenas quando o contexto de "heartbeat" não for suficiente.

Decisão de triagem por issue

Para cada issue, classifique em exatamente uma das seguintes opções:

1. Retomar — o caminho de execução está ativo. Confirme se o atribuído está definido e deixe o "heartbeat" continuar. Não comente.
2. Precisa de despertar — o atribuído está parado sem continuação ativa. Poste um comentário que nomeie a resolução do bloqueio ou a ação concreta seguinte, e então deixe in_progress ou mova para todo para que o atribuído a pegue.
3. Reatribuir — o atribuído não tem a especialidade correta. Reatribua e defina in_review apenas se o novo atribuído for humano, caso contrário, deixe in_progress.
4. Desbloquear — uma entrada de blockedByIssueIds de primeira classe agora está done ou cancelled. Se cancelled, substitua-a ou remova-a de blockedByIssueIds. O alerta "bloqueios resolvidos" será disparado automaticamente quando todos estiverem done.
5. Escalar — a issue precisa de entrada do quadro, CTO ou usuário. Crie um request_confirmation, ask_user_questions ou request_board_approval e defina a issue para in_review.
6. Fechar — o trabalho está completo, duplicado ou não é mais relevante. Defina done ou cancelled com um motivo de uma linha.

Se você não conseguir classificar em menos de um minuto de leitura, escale em vez de adivinhar.

Heurísticas de estado travado

• in_progress sem comentários ou atualizações de documento nas últimas 24h e sem monitor ou continuação em fila → precisa de despertar.
• in_review sem participante revisor, sem interação pendente, sem aprovação — caminho de revisão inválido → reatribua a um revisor real ou mova para todo.
• blocked sem blockedByIssueIds, apenas texto livre "bloqueado por X" → converta para bloqueios de primeira classe ou mova para todo com uma ação nomeada.
• blocked com todos os bloqueios done → desbloqueie a issue definindo o status de volta; o atribuído será acordado.
• Issues filhas todas completas, mas a pai ainda in_progress → confirme a aceitação da pai, então feche.

Lista de "não fazer"

• Não @-mencione agentes durante a triagem; menções custam orçamento. Use reatribuição direta em vez disso.
• Não comente novamente em uma issue blocked se seu comentário mais recente também foi uma atualização de bloqueio sem resposta desde então.
• Não cancele issues entre equipes. Reatribua ao gerente responsável com um comentário.
• Não altere o status sem um comentário que explique a mudança.

Saída de uma passagem de triagem

Uma curta cadeia de comentários ou mensagem de resumo que lista, por issue tocada:

• ID e título da issue.
• Veredicto (retomar / precisa de despertar / reatribuir / desbloquear / escalar / fechar).
• A única ação que você tomou ou solicitou.

Esta é a barra para "a triagem está feita".