Fluxo de Projeto Ops

Esta habilidade transforma issues, PRs (Pull Requests) e tarefas do Linear desconectados em um único fluxo de execução.

Use-a quando o problema for coordenação, não codificação.

Quando Usar

• Triagem de backlogs de PRs ou issues abertos
• Decidir o que pertence ao Linear vs. o que deve permanecer apenas no GitHub
• Vincular trabalho ativo do GitHub a fluxos de execução internos
• Classificar PRs em "mesclar", "portar/reconstruir", "fechar" ou "pausar"
• Auditar se comentários de revisão, falhas de CI ou issues desatualizados estão bloqueando a execução

Modelo Operacional

• GitHub é a verdade pública e da comunidade
• Linear é a verdade de execução interna para trabalho ativo agendado
• Nem todo issue do GitHub precisa de um issue no Linear
• Crie ou atualize o Linear apenas quando o trabalho for:
  • ativo
  • delegado
  • agendado
  • multifuncional
  • importante o suficiente para ser rastreado internamente

Fluxo de Trabalho Principal

1. Leia a superfície pública primeiro

Colete:

• Estado do issue ou PR do GitHub
• Status do autor e do branch
• Comentários de revisão
• Status do CI
• Issues vinculados

2. Classifique o trabalho

Todo item deve terminar em um destes estados:

3. Decida se o Linear é justificado

Crie ou atualize o Linear apenas se:

• a execução estiver ativamente planejada
• múltiplos repositórios ou fluxos de trabalho estiverem envolvidos
• o trabalho precisar de propriedade ou sequenciamento interno
• o issue for parte de um fluxo de programa maior

Não espelhe tudo mecanicamente.

4. Mantenha os dois sistemas consistentes

Quando o trabalho estiver ativo:

• o issue/PR do GitHub deve dizer o que está acontecendo publicamente
• o Linear deve rastrear o proprietário, a prioridade e o fluxo de execução internamente

Quando o trabalho for enviado ou rejeitado:

• poste a resolução pública de volta no GitHub
• marque a tarefa do Linear de acordo

Regras de Revisão

• Nunca mescle apenas pelo título, resumo ou confiança; use o diff completo
• Funcionalidades de fontes externas devem ser reconstruídas dentro do ECC quando forem valiosas, mas não autocontidas
• CI vermelho significa classificar e corrigir ou bloquear; não finja que está pronto para mesclar
• Se o bloqueio real for a direção do produto, diga isso em vez de se esconder atrás de ferramentas

Formato de Saída

Retorne:

PUBLIC STATUS
- issue / PR state
- CI / review state

CLASSIFICATION
- merge / port-rebuild / close / park
- one-paragraph rationale

LINEAR ACTION
- create / update / no Linear item needed
- project / lane if applicable

NEXT OPERATOR ACTION
- exact next move

Bons Casos de Uso

• "Audite o backlog de PRs abertos e diga-me o que mesclar vs. reconstruir"
• "Mapeie issues do GitHub para nossos fluxos de programa ECC 1.x e ECC 2.0"
• "Verifique se isso precisa de um issue no Linear ou deve permanecer apenas no GitHub"