Project Flow Ops
Ce skill transforme les issues GitHub, les PR et les tâches Linear déconnectées en un seul flux d'exécution.
Utilisez-le lorsque le problème est la coordination, pas le codage.
Quand l'utiliser
- Trier les backlogs de PR ou d'issues ouvertes
- Décider ce qui appartient à Linear par rapport à ce qui doit rester uniquement sur GitHub
- Lier le travail actif GitHub aux voies d'exécution internes
- Classifier les PR en merge, port/reconstruction, fermeture ou mise en attente
- Auditer si les commentaires de revue, les échecs CI ou les issues obsolètes bloquent l'exécution
Modèle d'exploitation
- GitHub est la vérité publique et communautaire
- Linear est la vérité d'exécution interne pour le travail actif planifié
- Toutes les issues GitHub n'ont pas besoin d'une issue Linear
- Créer ou mettre à jour Linear uniquement lorsque le travail est :
- actif
- délégué
- planifié
- cross-fonctionnel
- suffisamment important pour être suivi en interne
Workflow principal
1. Lire d'abord la surface publique
Rassemblez :
- l'état de l'issue ou de la PR GitHub
- l'auteur et l'état de la branche
- les commentaires de revue
- l'état CI
- les issues liées
2. Classifier le travail
Chaque élément doit aboutir dans l'un de ces états :
| État | Signification |
|---|---|
| Merge | autonome, conforme à la politique, prêt |
| Port/Rebuild | idée utile, mais doit être réimplantée manuellement dans ECC |
| Close | mauvaise direction, obsolète, non sécurisé ou dupliqué |
| Park | 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'une voie de programme plus large
Ne pas tout refléter mécaniquement.
4. Maintenir la cohérence des deux systèmes
Lorsque le travail est actif :
- l'issue/PR GitHub doit indiquer publiquement ce qui se passe
- Linear doit suivre le propriétaire, la priorité et la voie d'exécution en interne
Lorsque le travail est livré ou rejeté :
- publier la résolution publique sur GitHub
- marquer la tâche Linear en conséquence
Règles de revue
- Ne jamais merger sur la base du titre, du résumé ou de la confiance seule ; utiliser la diff complète
- Les fonctionnalités provenant de sources externes doivent être reconstruites dans ECC lorsqu'elles sont précieuses mais non autonomes
- CI rouge signifie classer et corriger ou bloquer ; ne pas faire semblant que c'est prêt à merger
- Si le vrai bloqueur est la direction du produit, dites-le au lieu de vous cacher derrière l'outillage
Format de sortie
Retournez :
STATUT PUBLIC
- état de l'issue / PR
- état CI / revue
CLASSIFICATION
- merge / port-rebuild / close / park
- justification en un paragraphe
ACTION LINEAR
- créer / mettre à jour / aucun élément Linear nécessaire
- projet / voie si applicable
PROCHAINE ACTION OPÉRATEUR
- prochaine action exacte
Cas d'utilisation appropriés
- "Auditer le backlog de PR ouvertes et me dire quoi merger vs reconstruire"
- "Mapper les issues GitHub dans nos voies de programme ECC 1.x et ECC 2.0"
- "Vérifier si cela nécessite une issue Linear ou doit rester uniquement GitHub"