Operações de Fluxo de Projetos
Esta skill transforma issues desconexas do GitHub, PRs e tarefas do Linear em um único fluxo de execução.
Use quando o problema for coordenação, não codificação.
Quando Usar
- Triar backlogs de PRs ou issues abertas
- Decidir o que pertence ao Linear versus o que deve permanecer apenas no GitHub
- Vincular trabalho ativo do GitHub às faixas de execução interna
- Classificar PRs em mesclar, portar/recriar, fechar ou estacionar
- Auditar se comentários de revisão, falhas de CI ou issues obsoletas estão bloqueando a execução
Modelo Operacional
- GitHub é a verdade pública e comunitária
- Linear é a verdade de execução interna para trabalho ativo programado
- Nem toda issue do GitHub precisa de uma issue no Linear
- Crie ou atualize o Linear apenas quando o trabalho estiver:
- ativo
- delegado
- programado
- transversal
- suficientemente importante para ser rastreado internamente
Fluxo de Trabalho Principal
1. Leia primeiro a superfície pública
Reúna:
- estado da issue ou PR no GitHub
- autor e status do branch
- comentários de revisão
- status do CI
- issues vinculadas
2. Classifique o trabalho
Cada item deve terminar em um destes estados:
| Estado | Significado |
|---|---|
| Mesclar | autocontido, em conformidade com as políticas, pronto |
| Portar/Recriar | ideia útil, mas deve ser reimplementada manualmente dentro da ECC |
| Fechar | direção errada, obsoleto, inseguro ou duplicado |
| Estacionar | potencialmente útil, mas não programado agora |
3. Decida se o Linear é justificado
Crie ou atualize o Linear apenas se:
- a execução estiver ativamente planejada
- vários repositórios ou fluxos de trabalho estiverem envolvidos
- o trabalho precisar de propriedade ou sequenciamento internos
- a issue fizer parte de uma faixa de programa maior
Não espelhe tudo mecanicamente.
4. Mantenha os dois sistemas consistentes
Quando o trabalho estiver ativo:
- issue/PR do GitHub deve dizer o que está acontecendo publicamente
- Linear deve rastrear o responsável, prioridade e faixa de execução internamente
Quando o trabalho for enviado ou rejeitado:
- publique a resolução pública de volta no GitHub
- marque a tarefa no Linear de acordo
Regras de Revisão
- Nunca mescle baseado apenas no título, resumo ou confiança; use o diff completo
- Funcionalidades de fontes externas devem ser recriadas dentro da ECC quando forem valiosas, mas não autossuficientes
- CI vermelho significa classificar e corrigir ou bloquear; não finja que está pronto para mesclar
- Se o verdadeiro bloqueador for a direção do produto, diga isso em vez de se esconder atrás de ferramentas
Formato de Saída
Retorne:
STATUS PÚBLICO
- estado da issue / PR
- estado do CI / revisão
CLASSIFICAÇÃO
- mesclar / portar-recriar / fechar / estacionar
- justificativa de um parágrafo
AÇÃO NO LINEAR
- criar / atualizar / nenhum item do Linear necessário
- projeto / faixa se aplicável
PRÓXIMA AÇÃO DO OPERADOR
- próximo passo exato
Bons Casos de Uso
- "Audite o backlog de PRs abertos e me diga o que mesclar vs recriar"
- "Mapeie issues do GitHub em nossas faixas de programa ECC 1.x e ECC 2.0"
- "Verifique se isso precisa de uma issue no Linear ou deve permanecer apenas no GitHub"