Vers des Tickets
Décomposez un plan, une spécification ou une conversation en un ensemble de tickets : des tranches verticales de type traceur-balle, chacune déclarant les tickets qui la bloquent.
Le vocabulaire du tracker de tickets et des labels de triage doit vous avoir été fourni. Sinon, demandez à l'utilisateur d'exécuter /setup-matt-pocock-skills.
Processus
1. Recueillir le contexte
Partez de ce qui est déjà présent dans le contexte de la conversation. Si l'utilisateur fournit une référence (chemin d'une spécification, numéro de ticket ou URL) en argument, récupérez-la et lisez l'intégralité de son corps et de ses commentaires.
2. Explorer la base de code (optionnel)
Si vous n'avez pas encore exploré la base de code, faites-le pour comprendre l'état actuel du code. Les titres et descriptions des tickets doivent utiliser le glossaire du domaine du projet et respecter les ADR (Architecture Decision Records) dans la zone que vous touchez.
Cherchez des opportunités de préfactoriser le code pour faciliter l'implémentation. « Rendez le changement facile, puis faites le changement facile. »
3. Rédiger les tranches verticales
Décomposez le travail en tickets de type traceur-balle.
<règles-tranches-verticales>
- Chaque tranche découpe un chemin ÉTROIT mais COMPLET à travers chaque couche (schéma, API, UI, tests) : vertical, PAS une tranche horizontale d'une seule couche
- Une tranche terminée est démoable ou vérifiable par elle-même
- Chaque tranche est dimensionnée pour tenir dans une seule fenêtre de contexte fraîche
- Toute préfactorisation doit être effectuée en premier
</règles-tranches-verticales>
Attribuez à chaque ticket ses dépendences de blocage : les autres tickets qui doivent être terminés avant qu'il puisse commencer. Un ticket sans bloqueur peut commencer immédiatement.
Les refontes larges sont l'exception au découpage vertical. Une refonte large est un changement mécanique unique (renommer une colonne, retaper un symbole partagé) dont le rayon d'impact s'étend sur toute la base de code, de sorte qu'une seule modification casse des milliers de sites d'appel à la fois et qu'aucune tranche verticale ne peut être fusionnée en vert. Ne forcez pas cela dans un ticket traceur-balle ; séquencez-le en expand–contract. D'abord, expand : ajoutez la nouvelle forme à côté de l'ancienne pour que rien ne casse. Ensuite, migrez les sites d'appel par lots dimensionnés par rayon d'impact (par paquet, par répertoire), chaque lot étant son propre ticket bloqué par l'expand, en maintenant CI vert lot après lot car l'ancienne forme existe toujours. Enfin, contract : supprimez l'ancienne forme une fois qu'aucun appelant ne reste, dans un ticket bloqué par chaque lot de migration. Même lorsque les lots ne peuvent pas rester verts seuls, conservez la séquence mais laissez-les partager une branche d'intégration qui bloque tous un dernier ticket d'intégration-et-vérification ; le vert n'est promis qu'à cet endroit.
4. Interroger l'utilisateur
Présentez la décomposition proposée sous forme de liste numérotée. Pour chaque ticket, montrez :
- Titre : nom court descriptif
- Bloqué par : quels autres tickets (le cas échéant) doivent se terminer en premier
- Ce qu'il apporte : le comportement de bout en bout que ce ticket rend fonctionnel
Demandez à l'utilisateur :
- La granularité vous semble-t-elle correcte ? (trop grossière / trop fine)
- Les dépendences de blocage sont-elles correctes : chaque ticket ne dépend-il que de tickets qui le bloquent réellement ?
- Des tickets doivent-ils être fusionnés ou divisés davantage ?
Itérez jusqu'à ce que l'utilisateur approuve la décomposition.
5. Publier les tickets dans le tracker configuré
Publiez les tickets approuvés. La manière dépend du tracker configuré par /setup-matt-pocock-skills ; les tickets sont les mêmes dans les deux cas, seule la forme des dépendences de blocage change :
- Fichiers locaux → écrivez un fichier par ticket sous
.scratch/<slug-fonctionnalité>/issues/<NN>-<slug>.md, numérotés à partir de01dans l'ordre des dépendances (bloqueurs en premier). Chaque fichier liste dans « Bloqué par » les numéros/titres dont il dépend. Utilisez le modèle de fichier par ticket ci-dessous : un ticket par fichier, jamais un fichier combiné unique. - Un tracker de tickets réel (GitHub, Linear, …) → publiez un ticket par ticket dans l'ordre des dépendances (bloqueurs en premier) afin que chaque ticket puisse référencer des identifiants réels. Utilisez la relation de blocage / sous-ticket native de la plateforme si elle en a une ; sinon, définissez le champ « Bloqué par » de chaque ticket avec les tickets bloquants. Appliquez le label de triage
ready-for-agentsauf indication contraire ; les tickets sont naturellement récupérables par les agents.
Travaillez la frontière : tout ticket dont tous les bloqueurs sont terminés. Pour une chaîne purement linéaire, cela signifie du haut vers le bas.
Ne FERMEZ ni ne modifiez aucun ticket parent.
<modèle-fichier-local>
:
Ce qu'il faut construire : le comportement de bout en bout que ce ticket rend fonctionnel, du point de vue de l'utilisateur, et non une liste d'implémentation couche par couche.
Bloqué par : les numéros/titres des tickets qui bloquent celui-ci, ou « Aucun (peut commencer immédiatement) ».
Statut : ready-for-agent
- Critère d'acceptation 1
- Critère d'acceptation 2
</modèle-fichier-local>
<modèle-ticket>
Parent
Une référence au ticket parent sur le tracker (si la source était un ticket existant, sinon omettre cette section).
Ce qu'il faut construire
Le comportement de bout en bout que ce ticket rend fonctionnel, du point de vue de l'utilisateur, et non une implémentation couche par couche.
Critères d'acceptation
- Critère 1
- Critère 2
Bloqué par
- Une référence à chaque ticket bloquant, ou « Aucun (peut commencer immédiatement) ».
</modèle-ticket>
Dans les deux formes, évitez les chemins de fichiers spécifiques ou les extraits de code : ils deviennent vite obsolètes. Exception : si un prototype a produit un extrait qui encode une décision plus précisément que la prose (machine à états, réducteur, schéma, forme de type), intégrez-le et mentionnez brièvement qu'il provient d'un prototype. Réduisez-le aux parties riches en décisions, pas à une démo fonctionnelle, juste les éléments importants.