Project Flow Ops
Cette compétence transforme des issues GitHub, des PRs et des tâches Linear déconnectés en un flux d'exécution unique.
Utilisez-la lorsque le problème est la coordination, pas le codage.
Quand l'utiliser
- Trier les backlogs de PR ou d'issues ouverts
- Décider ce qui doit aller dans Linear par rapport à ce qui doit rester uniquement sur GitHub
- Lier le travail actif sur GitHub aux pistes d'exécution internes
- Classifier les PRs en fusion, port/rebuild, fermeture ou mise en attente
- Auditer si les commentaires de révision, les échecs CI ou les issues stagnantes bloquent l'exécution
Modèle de fonctionnement
- GitHub est la vérité publique et communautaire
- Linear est la vérité d'exécution interne pour le travail actif planifié
- Toute issue GitHub n'a pas besoin d'une issue Linear correspondante
- Créer ou mettre à jour Linear uniquement lorsque le travail est :
- actif
- délégué
- planifié
- interfonctionnel
- suffisamment important pour être suivi en interne
Flux de travail principal
1. Lire d'abord la surface publique
Rassembler :
- État de l'issue ou de la PR GitHub
- Auteur et statut de la branche
- Commentaires de révision
- Statut CI
- Issues liées
2. Classifier le travail
Chaque élément doit aboutir dans l'un de ces états :
| État | Signification |
|---|---|
| Fusion | autonome, conforme à la politique, prêt |
| Port/Rebuild | idée utile, mais doit être réintégrée manuellement dans ECC |
| Fermer | mauvaise direction, obsolète, non sécurisé ou dupliqué |
| Mettre en attente | potentiellement utile, mais non planifié maintenant |
3. Décider si Linear est justifié
Créer ou mettre à jour Linear uniquement si :
- l'exécution est activement planifiée
- plusieurs dépôts ou flux de travail sont impliqués
- le travail nécessite une propriété ou un séquencement interne
- l'issue fait partie d'un programme plus large
Ne pas tout refléter mécaniquement.
4. Maintenir la cohérence des deux systèmes
Quand le travail est actif :
- L'issue/PR GitHub doit dire ce qui se passe publiquement
- Linear doit suivre le propriétaire, la priorité et la piste d'exécution en interne
Quand le travail est livré ou rejeté :
- Publier la résolution publique sur GitHub
- Marquer la tâche Linear en conséquence
Règles de révision
- Ne jamais fusionner sur la base du titre, du résumé ou de la seule confiance ; utiliser la diff complète
- Les fonctionnalités provenant de sources externes doivent être reconstruites dans ECC lorsqu'elles sont utiles mais non autonomes
- CI rouge signifie classifier et corriger ou bloquer ; ne pas faire semblant que c'est prêt à fusionner
- Si le vrai bloqueur est l'orientation produit, le dire au lieu de se cacher derrière des outils
Format de sortie
Retourner :
STATUT PUBLIC
- état de l'issue / PR
- état CI / révision
CLASSIFICATION
- fusion / port-rebuild / fermer / mettre en attente
- justification en un paragraphe
ACTION LINEAR
- créer / mettre à jour / aucun élément Linear nécessaire
- projet / piste si applicable
PROCHAINE ACTION POUR L'OPÉRATEUR
- prochaine action exacte
Cas d'utilisation pertinents
- "Auditer le backlog de PR ouvertes et me dire quoi fusionner vs reconstruire"
- "Mapper les issues GitHub dans nos pistes de programme ECC 1.x et ECC 2.0"
- "Vérifier si cela nécessite une issue Linear ou doit rester uniquement sur GitHub"