g-ki/agent-skills

Découpage de Tâches

Transformez une conception en un backlog de tickets de 1 story-point que n'importe quel·le ingénieur·e de l'équipe peut prendre en charge, terminer et fusionner par lui·elle-même.

Entrée

$ARGUMENTS

• Si un chemin est fourni, lisez ce document.
• Sinon, utilisez le RFC le plus récent ou un fichier *.notes.md d'une session de réflexion productive dans cette conversation ou sur le disque. Ce sont généralement des fichiers locaux non suivis (cherchez dans les dossiers ignorés par git comme .rfcs/, puis docs/rfcs/, docs/adr/, rfcs/). Si vous n'en trouvez aucun, demandez quel document ou quelle conception découper.
• Si la source présente des lacunes qui empêchent le découpage (pas de conception choisie, pas d'approche de déploiement), listez-les et demandez avant d'inventer des réponses. Les petites lacunes peuvent devenir des tickets de type spike à la place.

Ce que « 1 story-point » signifie ici

Un ticket fait 1 point lorsque toutes les conditions suivantes sont remplies. Si l'une échoue, divisez-le :

1. Une personne, environ une journée ou moins, tests et corrections de revue compris.
2. Une seule PR à relire avec un objectif unique. Un·e relecteur·rice peut la comprendre sans lire d'autres PR ouvertes.
3. Fusionnable de manière autonome. La branche principale reste verte et livrable après son intégration, ce qui signifie généralement que le nouveau comportement est caché derrière un flag ou n'est pas encore activé.
4. Testable. Il a 1 à 5 critères d'acceptation qu'une personne autre que l'auteur·rice peut vérifier.
5. Pas d'inconnues cachées. Si l'implémenteur·rice devrait faire des recherches avant de savoir quoi faire, c'est un spike, pas un récit.

Si l'équipe a sa propre définition d'un point, suivez-la et notez-la en haut du résultat.

Comment découper

Lisez le code avant de découper : confirmez que les fichiers, modules, schémas et tests que chaque ticket touche existent réellement, et nommez-les dans le ticket. Les tickets qui citent des chemins réels sont pris en charge ; les vagues restent dans le backlog.

Commencez par un squelette fonctionnel : la tranche de bout en bout la plus fine qui prouve que la conception fonctionne en production (souvent derrière un flag), puis épaississez-la. Cela place le risque en début de projet plutôt que de découvrir des problèmes d'intégration dans le dernier ticket.

Lorsqu'un ticket est trop gros, ces divisions fonctionnent généralement :

• Préparer, puis modifier. Extrayez d'abord une pure refactorisation (« rendre le changement facile, puis faire le changement facile »), avec des tests qui figent le comportement actuel avant la refactorisation.
• Étendre / migrer / contracter pour les modifications de schéma et d'API : ajoutez la nouvelle colonne ou le nouvel endpoint, faites un backfill ou une double écriture, basculez les lectures, puis supprimez l'ancien chemin. Chaque phase est son propre ticket.
• Par couche derrière un flag : modèle de données → logique de service → API → UI, chacun fusionnable car le flag est désactivé.
• Chemin de lecture avant chemin d'écriture, et chemin heureux avant les cas limites et la gestion d'erreurs.
• Par variante : un ticket par fournisseur, type de fichier ou client, après que le premier ticket a établi le modèle.
• Spikes pour les inconnues : limités dans le temps (≤ 1 jour), et le résultat est une décision plus des tickets de suivi, pas du code de production. Donnez à chaque spike une Question: qui a une réponse, et une durée limite. Les tickets qui dépendent de la décision ne sont découpés qu'à un niveau sûr, avec une note indiquant qu'ils seront raffinés une fois le spike décidé. Placez les spikes tôt : ils bloquent tout ce qui suit.

N'oubliez pas le travail qui n'est pas du code fonctionnel : mise en place et suppression de feature flags, métriques/alertes/tableaux de bord, mises à jour de runbook ou de documentation, backfills de données, étapes de déploiement progressif, et nettoyage de l'ancien chemin. C'est généralement là que les projets « presque terminés » s'enlisent.

Ne divisez pas pour le plaisir de diviser : un ticket qui n'a de sens que fusionné avec un autre devrait être un seul ticket, ou la paire devrait être redécoupée selon une autre jointure.

Résultat

1. Écrivez le backlog en utilisant templates/tasks.md dans <nom-du-rfc>.tasks.md à côté du RFC source. Comme le RFC, c'est un fichier de travail local, non suivi par défaut ; si son dossier n'est pas encore ignoré par git, ajoutez-le à .git/info/exclude. Numérotez les tickets T-01, T-02, … afin que les dépendances puissent y faire référence, définissez chaque statut sur open, et remplissez le slug de projet utilisé pour les noms de branches. Conservez les noms de champs exactement comme dans le modèle, car /implement-task et /deliver-project les lisent.
2. Regroupez les tickets en jalons qui correspondent aux phases du RFC, chacun se terminant par quelque chose de démontrable ou livrable.
3. Incluez le graphe des dépendances : quels tickets peuvent s'exécuter en parallèle, et le chemin critique. Un petit graphe Mermaid fonctionne bien lorsqu'il y a plus d'environ 8 tickets.
4. En chat, donnez un court résumé : nombre de tickets par jalon, combien peuvent démarrer immédiatement, le chemin critique, les spikes, et tout ticket dont vous n'êtes pas sûr qu'il fasse vraiment 1 point. Demandez à l'utilisateur·rice de signaler les tickets qui semblent trop gros, trop petits ou mal ordonnés, et révisez.
5. Publiez dans le tracker de l'équipe. Supposez que l'équipe en utilise un (Linear, Jira, GitHub Issues, …). Une fois que l'utilisateur·rice est satisfait·e du découpage, proposez de le publier via l'outil de tracker connecté ; si aucun n'est connecté, dites quel connecteur aiderait, et proposez un CSV avec les colonnes ID, Title, Description, Acceptance Criteria, Story Points, Milestone, Depends On, Labels en solution de repli. Ne publiez qu'après confirmation de l'utilisateur·rice, car c'est visible par toute l'équipe. Pour chaque ticket, créez un issue avec le titre, une description autonome (contexte, périmètre, fichiers, hors périmètre, critères d'acceptation), une estimation à 1, le jalon, et les relations de blocage pour ses dépendances là où le tracker les supporte. Ensuite, écrivez la clé et le lien de chaque issue dans le champ Tracker: du fichier local.
6. Indiquez l'étape suivante : /implement-task <id-du-ticket> pour un seul ticket, /spike-task <id-du-ticket> pour un spike, ou /deliver-project <fichier-des-taches> pour exécuter l'ensemble du backlog avec une équipe d'agents.

Si le RFC source a une section de plan d'exécution, mettez-la à jour pour faire référence au fichier de tâches au lieu de dupliquer la liste.

Raffinement après un spike

Lorsqu'on vous donne le compte-rendu de décision d'un spike terminé (statut decided), mettez à jour le backlog au lieu de repartir de zéro :

1. Appliquez les modifications approuvées du backlog : ajoutez des tickets (continuez la numérotation T-NN, ne réutilisez jamais d'ID), modifiez le périmètre, les critères ou les dépendances des tickets concernés, et marquez les tickets supprimés comme canceled avec la raison plutôt que de les supprimer.
2. Revérifiez chaque ticket modifié ou nouveau par rapport au test du 1 point, et mettez à jour le résumé, le graphe des dépendances et le chemin critique.
3. Mettez à jour les sections du RFC listées dans le compte-rendu.
4. Synchronisez le tracker : créez les nouveaux issues, mettez à jour ceux modifiés, et annulez ceux supprimés, en écrivant les nouvelles clés dans le fichier de tâches. Si l'utilisateur·rice a approuvé la décision et ses modifications du backlog ensemble, cette approbation couvre cette synchronisation ; sinon confirmez d'abord.
5. Passez le spike à done et résumez ce qui a changé en quelques lignes.