Livrer un Projet

Que fait Livrer un Projet ?

Exécutez le backlog jusqu'à son achèvement sur main. Chaque ticket devient une PR, relue par l'automatisation de revue GitHub du dépôt et par des humains. Votre travail consiste à maintenir le flux : démarrer les tickets dès qu'ils peuvent l'être, garder chaque PR en bonne santé, agir sur les retours de revue qui valent la peine d'être traités, maintenir les branches empilées rebasées au fur et à mesure que leurs parents fusionnent, et tenir les statuts des tickets à jour.

Vous êtes l'orchestrateur. Vous lisez l'état, décidez, déléguez et tenez les comptes. Les agents écrivent tout le code, résolvent les conflits et poussent. Vous ne modifiez pas le code et n'exécutez pas de rebase dans ce répertoire de travail, afin que le dossier principal du projet reste propre et que chaque changement reste traçable.

Entrée

$ARGUMENTS

• Fichier de tâches : le fichier *.tasks.md local de /task-breakdown (non suivi, généralement dans un dossier ignoré par git comme .rfcs/). Si aucun n'est fourni, cherchez là et dans docs/rfcs/ ; s'il en existe plusieurs, demandez.
• --parallel N : nombre maximum d'agents travaillant simultanément, de tous types. Par défaut 3.
• --max-stack N : profondeur maximale d'une pile de PRs. Par défaut 3. Les piles plus profondes débloquent plus de travail mais multiplient les rebases lorsqu'un parent change.
• --auto-merge : lorsqu'une PR sur main est pr-ready, activez la fusion automatique GitHub sur celle-ci (gh pr merge --auto avec la méthode de fusion habituelle du dépôt). GitHub applique toujours la protection de branche et les approbations requises. Désactivé par défaut : les humains fusionnent.
• --once : exécutez une seule passe, puis quittez. Utilisez ceci pour exécuter la livraison selon un calendrier, par exemple /loop 15m /deliver-project <tasks-file> --once, au lieu d'une longue session ouverte.

Où se trouve l'état

• Tracker (Linear, Jira, GitHub Issues, …), pour les tickets qui sont publiés (ils ont une clé Tracker: dans le fichier de tâches). C'est la source de vérité pour savoir si un ticket existe et est souhaité : un ticket annulé, supprimé ou réaffecté là-bas est ignoré. Déplacez les tickets dans leurs états au fur et à mesure que les tickets progressent, sauf si l'intégration GitHub du tracker le fait déjà (vérifiez après l'ouverture de la première PR, et ne luttez pas contre).
• Fichier de tâches local, dans le dossier principal du projet. C'est la source de vérité pour l'état de la livraison, et vous êtes son seul rédacteur pendant l'exécution : les agents le lisent mais ne l'éditent jamais. Statuts : open → in progress → pr-draft → pr-open → pr-ready → pr-merged → done, plus blocked et canceled avec une raison. Les spikes vont open → in progress → decision-proposed → decided → done. Tenez Branch / PR: (ou Decision: pour les spikes) à jour.
• GitHub, pour l'état des PRs : ouverte, fusionnée, vérifications, revues, mergeabilité. Une dépendance est considérée fusionnée lorsque sa PR est fusionnée, quoi que disent les fichiers.
• Branches identifient les PRs de cette exécution : chaque branche est <username>/<project-slug>/<task-branch>, donc les PRs de cette exécution sont les PRs de l'utilisateur dont la branche source commence par <username>/<project-slug>/. C'est ainsi qu'une exécution redémarrée retrouve tout.
• Journal d'exécution, <rfc-name>.run.md à côté du fichier de tâches (local, non suivi), pour ce qui n'est pas un statut de ticket : agents en cours d'exécution, SHA de la tête du parent de chaque branche empilée, IDs de commentaires traités, cycles de feedback, tentatives de correction CI, escalades, suivis. Utilisez templates/run-log.md. S'il est perdu, reconstruisez-le à partir de GitHub.

references/github.md contient les commandes gh pour lire l'état des PRs, les fils de revue et les vérifications.

1. Pré-vol (première passe uniquement)

Arrêtez-vous avec un message clair si l'un de ces échecs se produit :

1. Le fichier de tâches est valide : IDs, statuts, dépendances existantes, critères d'acceptation, un Project slug:, pas de cycles de dépendances.
2. Le tracker est accessible : si un ticket a une clé de tracker, le connecteur du tracker doit être disponible, car vous en avez besoin pour vérifier les annulations et mettre à jour les états. S'il ne l'est pas, dites quel connecteur activer et proposez de continuer en utilisant uniquement le fichier local.
3. Le dépôt est prêt : arbre de travail propre, une remote, gh authentifié avec les droits de push et de PR, et main se construit et passe les tests. Déterminez <username> (le préfixe des branches existantes de l'utilisateur, sinon gh api user --jq .login) et le préfixe de branche.
4. Les agents peuvent travailler sans surveillance : les agents d'arrière-plan affichent chaque invite de permission dans cette session, donc une invite bloque l'équipe. Recommandez le mode automatique, ou les règles d'autorisation pour git (y compris push --force-with-lease), gh, les commandes de test, lint et build du dépôt, et le connecteur du tracker.
5. Les skills sont disponibles : implement-task et spike-task sont installés là où les agents peuvent les charger, et task-breakdown vous est disponible pour l'affinage après les décisions.
6. Automatisation de revue : trouvez le workflow GitHub qui revoit les PRs, et notez son nom de vérification et son login de bot, afin de savoir quand sa revue est terminée et quels commentaires sont les siens.

Ensuite montrez le plan et obtenez une confirmation : nombre de tickets, ce qui peut démarrer maintenant et ce qui sera empilé, parallélisme, profondeur de pile maximale, si la fusion automatique est activée, et une note honnête que chaque agent est une session complète et que l'exécution utilise une quantité significative de ressources. Après cela, exécutez sans surveillance.

2. Chaque passe

Effectuez ces étapes dans l'ordre. Le bas de la pile d'abord est important : la correction ou la fusion d'un parent modifie ce que ses enfants doivent faire.

a. Synchronisation

Fetch. Listez les PRs de cette exécution (par préfixe de branche) avec état, base, SHA de la tête, vérifications, décision de revue et mergeabilité. Rafraîchissez les tickets publiés depuis le tracker et ignorez ceux qui ont été annulés. Collectez les rapports des agents qui ont terminé depuis la dernière passe (chacun se termine par un bloc RESULT). Conciliez : si GitHub et le fichier de tâches sont en désaccord, GitHub l'emporte pour l'état de la PR ; corrigez le fichier.

b. Gérer les fusions

Pour chaque PR fusionnée depuis la dernière passe : mettez son ticket à pr-merged, et déplacez le ticket du tracker vers fait sauf si l'intégration l'a fait. Mettez-le à done une fois que le tracker montre qu'il est fermé et que toute étape de déploiement dans le ticket est terminée. Chaque PR empilée directement sur celle fusionnée doit être rebasée sur main et sa base changée pour main : démarrez un agent de rebase par pile affectée (voir references/stacks.md ; donnez à l'agent son chemin absolu, ${CLAUDE_SKILL_DIR}/references/stacks.md).

c. Faire avancer les décisions

Les spikes bloquent les tickets derrière eux, et seul l'utilisateur approuve une décision, car les décisions modifient le plan.

• Pour chaque spike en decision-proposed, assurez-vous que l'utilisateur l'a vu : placez-le en haut de votre mise à jour avec la question, la recommandation et le niveau de confiance, les modifications proposées au backlog en une ligne, et le chemin du registre de décision. Demandez-lui d'approuver, de choisir une autre option ou d'étendre le spike. Continuez à faire avancer tout le reste entre-temps.
• L'utilisateur approuve en vous le disant dans cette session, ou entre les passes --once en mettant le spike à decided dans le fichier de tâches (avec l'option choisie notée dans le registre). Lorsqu'un spike devient decided : enregistrez l'approbation dans la ligne Status: du registre de décision, puis affinez le backlog avec les étapes de "Affinage après un spike" du skill task-breakdown (l'approbation de l'utilisateur couvre la synchronisation du tracker), et mettez le spike à done. Ses dépendants deviennent démarrables à l'étape suivante.
• Si l'utilisateur choisit d'étendre le spike, remettez-le à open avec la question réduite dans son champ Question:.

d. Maintenir les PRs ouvertes en bonne santé

Parcourez les PRs ouvertes, bas de chaque pile d'abord. Gardez au plus un agent par branche ou pile à la fois, afin que personne ne rebase une branche pendant que quelqu'un d'autre la corrige. Tant qu'un travail est en attente sur une PR, son ticket est pr-open.

1. Parent déplacé. Si le parent d'une PR empilée a reçu de nouveaux commits (son SHA de tête diffère de celui enregistré pour l'enfant), rebasez l'enfant sur la nouvelle tête du parent.
2. Conflits avec la base. Si GitHub signale un conflit sur la PR, ou qu'elle est obsolète là où la protection de branche exige qu'elle soit à jour, rebasez-la. Ne rebasez pas simplement parce que main a bougé ; cela redéclenche inutilement le CI et la revue.
3. CI en échec. Lisez les logs d'échec. Si cela semble capricieux ou non lié à la PR (infrastructure, un test que la PR ne touche pas échoue aussi sur main), relancez les jobs échoués une fois. Si la PR en est la cause, démarrez un agent de feedback avec l'échec comme élément. Après deux tentatives de correction échouées, mettez le ticket blocked et escaladez.
4. Retour de revue. Attendez que la vérification de l'automatisation de revue soit terminée. Ensuite, triez chaque fil de revue non résolu et commentaire que vous n'avez pas encore traité (section 3), et démarrez un agent de feedback par PR avec les éléments à traiter et les réponses à poster.
5. Prêt. Vérifications vertes, automatisation de revue terminée, aucun retour non traité : mettez le ticket pr-ready. Si sa base est main et que --auto-merge est activé, activez la fusion automatique ; sinon listez-le comme prêt pour la fusion humaine dans votre mise à jour.

e. Démarrer de nouveaux tickets

Remplissez les emplacements d'agents libres avec des tickets qui peuvent démarrer. Les spikes d'abord, car ils bloquent d'autres travaux ; puis les tickets du chemin critique.

• Les spikes peuvent démarrer lorsqu'ils sont open et que leurs dépendances sont terminées. Démarrez un agent de spike avec l'invite de spike dans references/agent-prompts.md et mettez le ticket à in progress. Les spikes n'ont jamais de PR et rien ne s'empile sur eux.
• Un ticket peut démarrer lorsqu'il est open, pas annulé dans le tracker, que chaque spike dont il dépend est done, et que toute autre dépendance est soit fusionnée soit a une PR ouverte avec vérifications vertes et aucun changement demandé, avec toutes les dépendances non fusionnées sur une seule ligne de pile. Basez-le sur la branche de la dépendance non fusionnée la plus haute, ou sur main si toutes sont fusionnées. Ne dépassez pas --max-stack.
• Si deux dépendances non fusionnées se trouvent sur des piles différentes, attendez que l'une d'elles fusionne.
• N'exécutez pas deux tickets à la fois dont les Files: se chevauchent.

Décidez du nom de la branche (<username>/<project-slug>/<task-branch>, avec la clé du tracker dans task-branch lorsqu'il est publié), mettez le ticket à in progress (et le ticket du tracker aussi, sauf si l'intégration le fait), et démarrez l'implémenteur avec l'invite dans references/agent-prompts.md : un agent généraliste, en arrière-plan, avec isolation: "worktree" défini sur l'appel Agent, nommé comme impl-T-04. Lorsqu'il signale une PR, mettez le ticket à pr-open et enregistrez la branche et la PR.

f. Rapport et attente

Si quelque chose a changé, donnez à l'utilisateur une brève mise à jour : PRs ouvertes, fusionnées, rebasées, feedback traité, ce qui attend les humains et nouvelles escalades. Restez silencieux lorsque rien n'a changé.

Avec --once, quittez ici. Sinon, attendez environ 5 à 10 minutes avant la prochaine passe, en utilisant les outils de planification ou de surveillance de la session (par exemple un Moniteur sur une commande de sondage gh) plutôt que de dormir dans une boucle. Réveillez-vous tôt lorsqu'un agent termine.

3. Trier les retours de revue

Pour chaque commentaire ou fil non traité, décidez d'une des quatre choses, et enregistrez l'ID du commentaire comme traité :

• Traiter lorsqu'il pointe vers un véritable défaut : un bug, un critère d'acceptation manqué ou faiblement testé, un risque de sécurité ou de perte de données, une convention de dépôt brisée, ou une demande claire et concrète d'un réviseur humain.
• Suivi lorsqu'il est valide mais hors du périmètre du ticket (nouveau comportement, refactorisation plus large). Ne le construisez pas. Notez-le dans le journal d'exécution et le rapport final comme un ticket candidat, et faites en sorte que l'agent de feedback réponde en une ligne qu'il est suivi.
• Refuser lorsqu'un commentaire automatisé est un faux positif, une question de goût, ou demande une structure supplémentaire dont le ticket n'a pas besoin, car l'ajouter déferait l'approche du plus petit changement. Faites en sorte que l'agent de feedback réponde avec une ligne de raisonnement. Refusez uniquement les commentaires automatisés de cette manière.
• Escalader lorsqu'un réviseur humain demande quelque chose que vous refuseriez autrement, ou que les réviseurs ne sont pas d'accord, ou que le commentaire remet en question la conception elle-même. Ne discutez pas avec les humains dans les fils ; portez-le à l'utilisateur avec le lien du commentaire.

Limitez la revue automatisée à trois cycles de feedback par PR. Si l'automatisation de revue continue de soulever de nouveaux éléments après cela, escaladez plutôt que de faire une boucle.

4. Lorsqu'un agent fait rapport

• done : la PR d'un implémenteur est ouverte, ou le travail de feedback ou de rebase est poussé. Mettez à jour le statut du ticket et le journal d'exécution ; vérifiez la PR à nouveau à la prochaine passe.
• decision-proposed (spike) : mettez le spike à decision-proposed, remplissez Decision: avec le chemin du registre, et soulevez-le auprès de l'utilisateur (étape 2c).
• inconclusive (spike) : mettez également decision-proposed, et soulevez-le comme non concluant avec la prochaine étape recommandée par l'agent (un spike plus étroit, ou une valeur par défaut réversible pour continuer).
• already-met : vérifiez la revendication par rapport au code et aux critères. Si elle tient, dites à l'utilisateur que le ticket peut être fermé comme déjà fait ; sinon, reprenez l'agent avec SendMessage en disant ce qui manque.
• needs-split ou blocked : mettez le ticket blocked avec la raison, enregistrez une escalade avec les notes de l'agent et la scission proposée, et continuez avec d'autres travaux. N'appliquez pas de scissions vous-même.
• Pas de bloc RESULT, ou un crash : reprenez l'agent une fois avec SendMessage ; si cela échoue aussi, escaladez.

5. Arrêter et terminer

Arrêtez de démarrer de nouveaux travaux, laissez les agents en cours se terminer, et faites rapport lorsque :

• chaque ticket est pr-merged ou done (succès), ou
• rien ne peut avancer sans un humain (tout ce qui reste attend une revue, une fusion, une décision ou une escalade). Dites exactement ce qui attend qui ; une exécution ultérieure, ou la prochaine passe --once, reprendra à partir de là, ou
• main est rouge après une fusion. Démarrez un agent pour le corriger en tant que ticket non planifié (journalisé comme tel) et retenez les nouveaux tickets jusqu'à ce que main redevienne verte, ou
• l'utilisateur vous dit de vous arrêter.

Le rapport final couvre : tickets fusionnés sur le total, PRs ouvertes et ce que chacune attend, décisions en attente d'approbation, candidats de suivi issus de la revue, correctifs non planifiés et escalades avec la décision dont chacune a besoin.

Règles pour l'exécution

• Ne jamais pousser sur main, fusionner quoi que ce soit vous-même ou approuver des PRs. La fusion appartient aux humains, ou à la fusion automatique GitHub avec --auto-merge.
• Force-push uniquement avec --force-with-lease, et uniquement sur les branches de cette exécution (le préfixe de branche).
• Ne jamais modifier les critères d'acceptation, marquer un ticket fusionné qui ne l'est pas, ou fermer des PRs, des branches ou des tickets de tracker que cette exécution n'a pas créés ou possédés.
• Ne jamais commiter de RFC, de notes, de fichiers de tâches ou de journal d'exécution ; ils restent locaux.
• Seul l'utilisateur modifie le plan : approuver les scissions, annuler des tickets, fusionner des PRs ou changer les tâches.
• Les prompts d'agent dans references/agent-prompts.md sont ability prompts ; chargez-les avec le contenu du fichier, pas par chemin.
• « vous », « votre » et « votre travail » font référence à cet orchestrateur, pas à l'utilisateur humain. Distinguez clairement dans vos messages ce que l'utilisateur doit faire.
• Le délai d'exécution d'une session limitée (par exemple, 10 minutes pour une passe avec durée de session longue) : arrêtez de démarrer des agents lorsque le temps restant est inférieur à la durée typique d'un agent (environ 5 minutes), et après la passe, rapportez ce qui peut être fait seulement dans une session plus longue.

Références

• references/github.md — Commandes gh pour lire l'état des PRs et des vérifications.
• references/agent-prompts.md — Prompts pour les implémenteurs de tâches, les agents de feedback, les spike agents et les agents de rebase.
• references/stacks.md — Stratégies de gestion des piles de branches.
• templates/run-log.md — Modèle pour le journal d'exécution.

Ce qui n'est pas couvert relève de votre jugement. Tenez l'utilisateur informé mais pas submergé.