Project Flow Ops
Este skill convierte issues, PRs y tareas de Linear desconectados en un flujo de ejecución unificado.
Úsalo cuando el problema sea la coordinación, no la programación.
Cuándo usarlo
- Realizar triaje de backlogs de PRs o issues abiertos
- Decidir qué pertenece a Linear y qué debe permanecer solo en GitHub
- Vincular trabajo activo de GitHub con carriles de ejecución internos
- Clasificar PRs en merge, port/rebuild, close o park
- Auditar si los comentarios de revisión, fallos de CI o issues obsoletos están bloqueando la ejecución
Modelo operativo
- GitHub es la verdad pública y comunitaria
- Linear es la verdad interna de ejecución para trabajo activo programado
- No todos los issues de GitHub necesitan un issue en Linear
- Crear o actualizar Linear solo cuando el trabajo sea:
- activo
- delegado
- programado
- multifuncional
- lo suficientemente importante como para rastrearlo internamente
Flujo de trabajo principal
1. Leer la superficie pública primero
Recopilar:
- Estado del issue o PR de GitHub
- Autor y estado de la rama
- Comentarios de revisión
- Estado del CI
- Issues vinculados
2. Clasificar el trabajo
Cada elemento debe terminar en uno de estos estados:
| Estado | Significado |
|---|---|
| Merge | Autocontenido, conforme a políticas, listo |
| Port/Rebuild | Idea útil, pero debe ser reimplementada manualmente dentro de ECC |
| Close | Dirección incorrecta, obsoleto, inseguro o duplicado |
| Park | Potencialmente útil, pero no programado ahora |
3. Decidir si Linear está justificado
Crear o actualizar Linear solo si:
- la ejecución está planificada activamente
- están involucrados múltiples repositorios o flujos de trabajo
- el trabajo necesita asignación interna o secuenciación
- el issue es parte de un carril de programa más grande
No dupliques todo mecánicamente.
4. Mantener los dos sistemas consistentes
Cuando el trabajo está activo:
- El issue/PR de GitHub debe decir públicamente lo que está sucediendo
- Linear debe rastrear al responsable, prioridad y carril de ejecución internamente
Cuando el trabajo se completa o se rechaza:
- Publicar la resolución pública de vuelta en GitHub
- Marcar la tarea de Linear en consecuencia
Reglas de revisión
- Nunca fusiones solo por el título, resumen o confianza; usa el diff completo
- Las funciones de fuentes externas deben reconstruirse dentro de ECC cuando sean valiosas pero no autocontenidas
- CI en rojo significa clasificar y corregir o bloquear; no finjas que está listo para fusionar
- Si el verdadero bloqueador es la dirección del producto, dilo en lugar de esconderte detrás de herramientas
Formato de salida
Devuelve:
ESTADO PÚBLICO
- estado del issue / PR
- estado del CI / revisión
CLASIFICACIÓN
- merge / port-rebuild / close / park
- justificación de un párrafo
ACCIÓN EN LINEAR
- crear / actualizar / no se necesita elemento en Linear
- proyecto / carril si aplica
PRÓXIMA ACCIÓN DEL OPERADOR
- próximo movimiento exacto
Casos de uso recomendados
- "Audita el backlog de PRs abiertos y dime qué fusionar vs reconstruir"
- "Mapea los issues de GitHub en nuestros carriles de programa ECC 1.x y ECC 2.0"
- "Verifica si esto necesita un issue en Linear o debe permanecer solo en GitHub"