Project Flow Ops
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 programação.
Quando Usar
- Triage de backlog 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 lanes internas de execução
- Classificar PRs em merge, port/rebuild, close ou park
- 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 interna de execução para trabalho ativo agendado
- Nem toda issue do GitHub precisa de uma 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
Reúna:
- Estado da issue ou PR do 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 |
|---|---|
| Merge | autocontido, em conformidade com as políticas, pronto |
| Port/Rebuild | ideia útil, mas deve ser reimplementada manualmente dentro do ECC |
| Close | direção errada, obsoleto, inseguro ou duplicado |
| Park | potencialmente útil, mas não agendado agora |
3. Decida se o Linear é justificado
Crie ou atualize o Linear apenas se:
- a execução está ativamente planejada
- vários repositórios ou fluxos de trabalho estão envolvidos
- o trabalho precisa de ownership interno ou sequenciamento
- a issue faz parte de uma lane de programa maior
Não espelhe tudo mecanicamente.
4. Mantenha os dois sistemas consistentes
Quando o trabalho está ativo:
- A issue/PR do GitHub deve dizer o que está acontecendo publicamente
- O Linear deve rastrear owner, prioridade e lane de execução internamente
Quando o trabalho é entregue ou rejeitado:
- publique a resolução de volta no GitHub
- marque a tarefa no Linear de acordo
Regras de Revisão
- Nunca faça merge baseado apenas no 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 merge
- Se o verdadeiro bloqueador for a direção do produto, diga isso em vez de esconder atrás de ferramentas
Formato de Saída
Retorne:
STATUS PÚBLICO
- estado da issue / PR
- estado do CI / revisão
CLASSIFICAÇÃO
- merge / port-rebuild / close / park
- justificativa de um parágrafo
AÇÃO NO LINEAR
- criar / atualizar / nenhum item no Linear necessário
- projeto / lane se aplicável
PRÓXIMA AÇÃO DO OPERADOR
- próxima ação exata
Casos de Bom Uso
- "Audite o backlog de PRs abertos e me diga o que fazer merge vs reconstruir"
- "Mapeie issues do GitHub em nossas lanes de programa ECC 1.x e ECC 2.0"
- "Verifique se isso precisa de uma issue no Linear ou deve permanecer apenas no GitHub"