finishing-a-development-branch

Vue d’ensemble

À quoi sert cette skill

La skill finishing-a-development-branch vous aide à finaliser en toute sécurité une branche Git de développement une fois le travail implémenté et la suite de tests passée. Elle vous guide à travers un workflow clair et reproductible pour choisir si vous voulez faire un merge local, pousser et ouvrir une Pull Request, laisser la branche pour plus tard ou la supprimer complètement.

Le principe central de la skill est simple :

Vérifier les tests → Déterminer la branche de base → Proposer des options → Exécuter le choix → Nettoyer

Au lieu d’enchaîner des commandes Git ad hoc ou d’oublier des vérifications importantes, finishing-a-development-branch fournit à votre agent une checklist cohérente pour la fin d’une branche de feature ou de bugfix.

Pour qui est finishing-a-development-branch ?

• Développeurs travaillant avec des branches Git et souhaitant une routine structurée de « fin de branche »
• Équipes qui exigent des tests au vert avant un merge ou l’ouverture d’une PR
• Utilisateurs de l’ensemble de skills obra/superpowers qui veulent que les agents gèrent les workflows Git de manière plus sûre
• Toute personne qui se demande régulièrement : « Est-ce que cette branche est prête à être mergée, et comment dois-je l’intégrer ? »

Cette skill s’intègre particulièrement bien dans des dépôts qui disposent déjà de tests automatisés et de branches de base standard comme main ou master.

Problèmes résolus par cette skill

• Oublier de lancer les tests avant de faire un merge ou d’ouvrir une Pull Request
• Ne plus être sûr de la branche à partir de laquelle une branche de feature a été créée
• Prendre des décisions incohérentes entre merge local, PR ou abandon du travail
• Laisser des branches orphelines qui encombrent le dépôt faute de processus de clôture clair

En imposant un contrôle « tests d’abord » puis en présentant un petit nombre d’options explicites, finishing-a-development-branch réduit les erreurs et rend votre workflow Git prévisible.

Quand cette skill est-elle adaptée ?

Utilisez finishing-a-development-branch lorsque :

• Une fonctionnalité ou un correctif est entièrement implémenté
• Vous vous attendez à ce que tous les tests passent ou que vous souhaitiez bloquer l’intégration en cas d’échec des tests
• Vous êtes prêt à décider comment cette branche doit être intégrée ou si elle doit être abandonnée

Cette skill n’est pas adaptée lorsque :

• Vous êtes encore en phase de développement actif ou d’expérimentation sur la branche
• Le dépôt ne dispose d’aucun test exploitable et vous ne pouvez pas exécuter de suite de tests pertinente
• Vous avez besoin d’une gestion de release multi-branches complexe, au-delà d’un simple flux feature → branche de base

Si votre besoin principal est d’obtenir de l’aide pour écrire du code ou relire des changements, pensez à combiner cette skill avec d’autres orientées implémentation ou revue de code ; finishing-a-development-branch se concentre spécifiquement sur la phase finale d’intégration.

Comment l’utiliser

Installation et configuration

1. Installer la skill

Installez finishing-a-development-branch depuis le dépôt obra/superpowers à l’aide du Skills CLI :

npx skills add https://github.com/obra/superpowers --skill finishing-a-development-branch

Cela rend la skill disponible dans l’environnement de votre agent, afin qu’elle puisse appliquer le workflow Git guidé à votre dépôt actuel.

2. Vérifier les prérequis du dépôt

Pour que la skill se comporte comme prévu, votre projet doit :

• Être un dépôt Git avec une branche de base bien définie (souvent main ou master).
• Disposer d’une suite de tests exécutable, généralement via des commandes comme :
  • npm test
  • cargo test
  • pytest
  • go test ./...

La commande exacte dépend de votre stack ; la skill part du principe qu’il existe une commande de test et qu’elle peut être exécutée avant l’intégration.

3. Annoncer l’utilisation de la skill

Lorsque vous démarrez le processus de finalisation, la skill s’attend à ce que vous (ou votre agent) annonciez explicitement :

"I'm using the finishing-a-development-branch skill to complete this work."

Cela rend le workflow transparent pour vos collaborateurs et indique que le processus structuré est en cours.

Étapes du workflow guidé

Étape 1 : Vérifier les tests

Avant de prendre une décision d’intégration, la skill lance (ou vous demande de lancer) la suite de tests du projet. Les commandes typiques incluent :

npm test
# or
cargo test
# or
pytest
# or
go test ./...

• Si les tests échouent : la skill indique le nombre d’échecs, affiche les erreurs et interrompt le processus. Elle signale qu’elle ne peut pas poursuivre vers un merge ou une PR tant que les tests ne sont pas au vert.
• Si les tests passent : le workflow continue à l’étape suivante.

Ce verrou strict « tests d’abord » permet d’éviter de merger ou de proposer en Pull Request du code cassé.

Étape 2 : Déterminer la branche de base

Ensuite, finishing-a-development-branch identifie la branche à partir de laquelle votre branche de développement a été créée, en utilisant des commandes Git telles que :

git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null

Si la branche de base ne peut pas être déterminée automatiquement, la skill se rabat sur une question de clarification, par exemple :

"This branch split from main - is that correct?"

La confirmation de la bonne branche de base est importante, car elle détermine où votre travail sera mergé et quelle sera la cible de la Pull Request.

Étape 3 : Proposer les options d’intégration

Une fois les tests passés et la branche de base identifiée, la skill présente exactement quatre options concises :

Implementation complete. What would you like to do?

1. Merge back to <base-branch> locally
2. Push and create a Pull Request
3. Keep the branch as-is (I'll handle it later)
4. Discard this work

Which option?

Les options sont volontairement courtes et directes, sans explications superflues, pour faciliter un choix rapide.

Cas d’usage typiques :

• Option 1 – Vous souhaitez un merge local rapide, souvent dans de petits projets personnels ou lorsque vous êtes le seul mainteneur.
• Option 2 – Vous travaillez en équipe et avez besoin d’une revue de code, de CI ou d’approbations via une plateforme d’hébergement Git comme GitHub.
• Option 3 – Vous n’êtes pas prêt à décider, mais vous voulez confirmer que les tests passent et que l’état de la branche est clair.
• Option 4 – Il s’agissait d’une expérimentation ou l’approche est obsolète, et vous voulez supprimer proprement la branche.

Étape 4 : Exécuter l’option choisie

En fonction de votre réponse, la skill exécute les actions Git correspondantes et tout nettoyage associé. Même si le SKILL.md sous-jacent tronque certains détails de commandes, l’intention est :

• Pour le merge local : se positionner sur la branche de base, merger la branche de développement, puis, si approprié, supprimer la branche terminée.
• Pour push + PR : pousser la branche sur le remote et vous guider pour créer une Pull Request ciblant la branche de base identifiée.
• Pour garder la branche telle quelle : laisser la branche actuelle intacte et noter clairement que vous prendrez en charge l’intégration plus tard.
• Pour abandonner : supprimer ou abandonner la branche en toute sécurité après confirmation que c’est bien ce que vous souhaitez.

Tout au long de cette étape, la skill met l’accent sur la prévisibilité et la sécurité : ne pas merger avec des tests en échec, ne pas merger dans la mauvaise branche de base, et éviter toute perte de travail accidentelle.

Conseils pratiques d’utilisation

Intégrer la skill dans votre workflow personnel

• Exécutez finishing-a-development-branch dès que vous considérez qu’une feature est « terminée ».
• Laissez le contrôle des tests servir de dernier garde-fou qualité avant de choisir entre merge et PR.
• En contexte d’équipe, utilisez l’Option 2 par défaut pour déclencher les revues et pipelines de CI.

Aligner l’usage avec les conventions de l’équipe

Si votre équipe suit des règles spécifiques de branches et de revue (par exemple, toujours ouvrir des PR vers develop en premier, ou ne jamais supprimer automatiquement les branches), alignez votre utilisation des options sur ces règles. La structure de la skill facilite l’application cohérente de ces politiques.

Combiner avec d’autres skills superpowers

Au sein de la suite obra/superpowers, finishing-a-development-branch est conçue pour compléter des skills qui aident à l’implémentation, au refactoring ou aux tests. Utilisez ces dernières pour faire évoluer la branche, puis appelez cette skill lorsque vous êtes réellement prêt à intégrer.

FAQ

Quand dois-je lancer la skill finishing-a-development-branch ?

Lancez finishing-a-development-branch lorsque vos changements sont implémentés, que vous vous attendez à ce que les tests passent et que vous êtes prêt à décider comment intégrer la branche (merge, PR, conservation ou abandon). Elle est pensée comme la dernière étape du cycle de vie d’une branche, pas comme un assistant de développement quotidien.

Que se passe-t-il si les tests échouent ?

Si les tests échouent, la skill signale les échecs et interrompt le processus. Elle ne poursuivra pas vers un merge ni vers la création d’une Pull Request. Vous devez corriger les tests en échec sur la branche, les relancer, puis invoquer à nouveau finishing-a-development-branch.

Puis-je l’utiliser sans suite de tests automatisée ?

La skill est construite autour du principe « vérifier les tests d’abord ». Même si, en théorie, vous pourriez l’adapter à un projet sans tests, vous contourneriez l’un de ses garde-fous essentiels. Pour de meilleurs résultats, utilisez-la dans des dépôts où vous pouvez exécuter des commandes telles que npm test, cargo test, pytest ou go test ./....

Comment décide-t-elle de la branche dans laquelle merger ?

finishing-a-development-branch tente de déterminer la branche de base en utilisant merge-base de Git sur des noms de branches courants comme main ou master. Si cela reste ambigu, elle vous demandera de confirmer la branche de base. Cela garantit que les merges et Pull Requests visent la bonne branche.

Crée-t-elle automatiquement une Pull Request ?

Le comportement documenté de la skill est de « push and create a Pull Request » lorsque vous choisissez l’Option 2. Les mécanismes précis dépendent de la façon dont l’environnement de votre agent est configuré avec votre plateforme d’hébergement Git. Au minimum, elle poussera votre branche et vous guidera pour ouvrir une PR contre la branche de base détectée.

Va-t-elle supprimer ma branche automatiquement ?

La description SKILL se concentre sur la présentation d’options et l’exécution du workflow choisi, y compris le nettoyage. Le comportement exact de suppression peut dépendre de la façon dont votre environnement interprète l’étape de nettoyage. Considérez l’Option 4 (discard this work) comme potentiellement destructive, et ne la choisissez que si vous êtes certain de ne plus avoir besoin de la branche.

finishing-a-development-branch convient-elle aux flux de release complexes ?

Cette skill cible des branches de feature ou de correctif simples, qui sont mergées dans une seule branche de base. Si vous gérez plusieurs branches de release long-terme, des hotfix complexes ou des pipelines de déploiement élaborés, vous pouvez toujours utiliser finishing-a-development-branch branche par branche, mais il vous faudra sans doute des processus ou outils complémentaires pour couvrir l’ensemble de la stratégie de release.

Comment réinstaller finishing-a-development-branch ?

Utilisez le Skills CLI en pointant vers le dépôt obra/superpowers :

npx skills add https://github.com/obra/superpowers --skill finishing-a-development-branch

Après l’installation, suivez le workflow de la skill : lancez les tests, confirmez la branche de base, choisissez une option et laissez la skill gérer les étapes d’intégration et de nettoyage.