Get Tasks
Vue d'ensemble
get-tasks convertit un PRD approuvé en un ensemble de tâches exécutables. Chaque tâche est écrite dans son propre fichier, dimensionnée pour une session de travail ciblée, ordonnée par dépendances, et accompagnée de critères d'acceptation, d'étapes de validation, d'une liste de blocages et d'une procédure de rollback.
La raison pour laquelle ce skill existe en tant que tel : un PRD n'est pas un plan. Un PRD décrit ce que le système fait et pourquoi. Il ne dit rien sur l'ordre du travail, ce qui peut être construit en parallèle, où se trouvent les parties risquées, ou comment prouver qu'une partie est terminée. Transformer un PRD directement en code produit soit un passage héroïque en une seule fois, soit un ordre arbitraire qui casse à mi-chemin.
get-tasks fournit la couche manquante. Il lit le PRD, cartographie la structure réelle des dépendances, découpe le travail en tranches verticales, et écrit chaque tranche comme un artefact autonome qu'un agent (ou un humain) peut prendre sans relire l'ensemble du PRD.
Ce skill s'inspire de trois sources :
- Décomposition basée sur les dépendances et découpage vertical — construire un graphe de dépendances, découper verticalement plutôt qu'horizontalement, dimensionner chaque tâche et placer des points de contrôle. C'est ce qui rend l'ordre correct.
- Exécution axée sur la validation — chaque tâche déclare comment elle sera vérifiée sur plusieurs types de validation, pas seulement « les tests passent », et comporte une procédure de replanification en cas d'échec d'une étape.
- Dépendances bloquantes et balles traçantes — chaque tâche indique explicitement ce qui la bloque, afin que toute tâche dont les blocages sont résolus puisse commencer immédiatement.
Le résultat est un répertoire de fichiers de tâches : tasks/<name>/task-01.md, task-02.md, etc., numérotés dans l'ordre des dépendances, plus tasks/<name>/plan.md qui les indexe. Les tâches bloquantes reçoivent les petits numéros.
Périmètre de ce Skill
get-tasks est délibérément complet. Il absorbe ce que plusieurs skills plus étroits faisaient chacun partiellement, de sorte qu'un utilisateur n'ait besoin que d'un seul skill pour passer d'un PRD approuvé à un plan exécutable et traçable. Tout ce qui est ici est pertinent pour ce seul travail :
| Préoccupation | Où elle est traitée |
|---|---|
| Lecture du PRD et extraction des engagements | Phase 1 |
| Structure des dépendances et ordonnancement | Phase 2 |
| Découpage vertical et balles traçantes | Phase 3 |
| Refontes larges (étendre, migrer, contracter) | Phase 3 |
| Spécification par tâche | Phase 4 |
| Règles de dimensionnement et de découpage | Phase 5 |
| Points de contrôle et portes | Phase 5 |
| Classification de la parallélisation | Taxonomie de parallélisation |
| Résumé lisible du plan, risques, décisions | Phase 6 |
| Cible du suivi vs fichier | Cible de la liste de tâches |
| Approbation de l'utilisateur avant écriture | Phase 7 |
| Écriture, synchronisation et vérification des artefacts | Phase 8 |
| Gestion des échecs et replanification | Replanification en cas d'échec d'une tâche |
Il est long par conception. La longueur est le point essentiel : une décomposition qui laisse l'un de ces éléments implicite produit des tâches qui semblent terminées mais ne le sont pas. Si vous êtes tenté de passer directement au modèle, lisez plutôt les phases 2, 3 et 5 — c'est là que les décompositions échouent réellement.
Ce que ce skill ne fait pas : il n'écrit pas de code, n'exécute pas les tâches et ne remplace pas le PRD. Il convertit un document en un ensemble de documents.
Quand l'utiliser
Utilisez ce skill quand :
- Un PRD, une spécification ou un document d'exigences existe et que le travail doit devenir des tâches exécutables
- L'utilisateur dit « get tasks », « breakdown PRD », « pecah jadi task », « bikin task list » ou « transforme ça en tâches »
- Une tâche semble trop grande pour être commencée et doit être décomposée
- Vous devez estimer le périmètre, ordonner le travail ou trouver ce qui peut être exécuté en parallèle
- Vous êtes sur le point d'implémenter quelque chose qui touche plus que quelques fichiers et qu'aucune liste de tâches n'existe
Quand NE PAS l'utiliser :
- Il n'existe pas encore de PRD — exécutez
get-prdd'abord, puis revenez - Le changement est une seule tâche par tous les critères (un fichier, une modification évidente) — faites-le simplement
- Une décomposition complète des tâches existe déjà dans
tasks/et vous êtes prêt à implémenter — passez directement à l'exécution des tâches dans l'ordre
Le Processus
get-tasks s'exécute en neuf phases. Chaque phase a une condition de sortie. N'avancez pas à une phase dont la condition de sortie n'est pas remplie.
0. Localiser le PRD -> quel document est la source ?
1. Lire et extraire -> à quoi le PRD nous engage-t-il ?
2. Graphe de dépendances -> qu'est-ce qui dépend de quoi ?
3. Tranches verticales -> balles traçantes, pas couches horizontales
4. Écrire chaque tâche -> un fichier par tâche, entièrement spécifié
5. Ordonner, dimensionner, point de contrôle -> séquence, taille et portes de vérification
6. Écrire le document de plan -> le résumé lisible qui indexe les tâches
7. Interroger l'utilisateur -> granularité, dépendances bloquantes, fusionner ou diviser
8. Écrire et vérifier -> fichiers sur disque, todos synchronisés, validateurs verts
Principes universels pour la décomposition des tâches
- Rythme en langage naturel : Présentez la décomposition et les résumés conversationnels dans la langue que parle l'utilisateur (indonésien ou anglais), tout en gardant les noms de fichiers, les termes git et les jetons de code standard (
task-01.md,branch,commit,TDD). - Prêt pour l'exécution autonome : Chaque fichier de tâche généré dans
tasks/<feature>/task-*.mddoit être complètement autonome. Tout agent de codage doit pouvoir lire ce seul fichier de tâche, savoir quels fichiers modifier, quels tests exécuter et quelle définition de « fait » doit être satisfaite sans deviner. - Tranches verticales plutôt que couches horizontales : Ne créez jamais de tâches qui sont purement « configurer le backend » ou « configurer le frontend » de manière isolée si elles ne peuvent pas être vérifiées de bout en bout. Découpez verticalement (par exemple « Stocker & interroger l'endpoint SKU avec déclencheur UI ») afin que chaque tâche apporte une valeur testable.
La planification est en lecture seule. Les phases 0 à 7 produisent des documents et des questions, pas de code. Ne créez, ne modifiez ni ne supprimez aucun fichier source pendant ces phases. L'écriture de fichiers de tâches sous tasks/ est le seul changement du système de fichiers autorisé avant que l'utilisateur n'approuve. Si vous vous retrouvez à corriger un bug ou à ajouter une fonction pendant la décomposition du travail, arrêtez-vous : cela appartient à l'implémentation post-approbation, et cela appartient à une tâche que vous n'avez pas encore écrite.
Phase 0 : Localiser le PRD
Trouvez le document source avant toute autre chose.
- Convention d'abord.
get-prdsauvegarde dansdocs/prd/<name>.md. Cherchez là d'abord. - Puis la recherche plus large. Si
docs/prd/est vide, cherchez un PRD que l'utilisateur nomme. Acceptez un corps d'issue ou un document d'exigences collé — le skill n'est pas lié au format, seule l'extraction de la phase 1 suppose les noms de sections du PRD. - S'il y a plus d'un candidat, ne devinez pas. Listez-les et demandez lequel régit ce travail.
- S'il n'y en a aucun, arrêtez-vous et dites-le. N'inventez pas d'exigences. Orientez l'utilisateur vers
get-prdpour un passage complet de l'entretien au PRD.
Enregistrez le chemin exact à partir duquel vous travaillez. Chaque phase ultérieure le référence.
Pour une initiative multi-modules où le PRD est divisé par identifiant de module (docs/prd/identity.md, docs/prd/billing.md), confirmez quel module cette décomposition couvre. Une décomposition par module, dans l'ordre de construction déclaré par la carte des capacités.
Condition de sortie : un seul document source est identifié, et son chemin est enregistré.
Phase 1 : Lire et Extraire
Lisez le PRD en entier. Ensuite, extrayez, explicitement, le matériel qui conduit la décomposition :
| Section du PRD | Ce que vous en extrayez |
|---|---|
| Objectif | L'état final que toutes les tâches servent en fin de compte |
| User Stories | Les comportements observables qui doivent fonctionner, critères d'acceptation candidats |
| Décisions techniques | Modules, interfaces, changements de schéma, contrats — ceux-ci définissent les vraies frontières entre les tâches |
| Structure du projet | Où les artefacts atterrissent, ce qui contraint les « fichiers susceptibles d'être touchés » |
| Commandes | Les commandes de vérification concrètes que chaque tâche citera |
| Stratégie de test | Ce qui compte comme un bon test ici, et où les tests appartiennent |
| Limites | Toujours / Demander d'abord / Jamais — les éléments Jamais deviennent des contraintes dures sur chaque tâche |
| Hors périmètre | Non-objectifs explicites ; rien ici ne devient une tâche |
| Critères de succès | La porte finale ; le dernier point de contrôle vérifie par rapport à eux |
Règles :
- Ne commencez pas à découper encore. Extraction d'abord, décomposition ensuite. Découper en lisant produit des tâches façonnées par l'ordre dans lequel vous avez lu le document.
- Convertissez les éléments vagues en déclarations vérifiables. Si le PRD dit « le tableau de bord doit être rapide », le critère d'acceptation de la tâche est un nombre, et si le PRD n'a donné aucun nombre, présentez-le comme un blocage plutôt que d'en choisir un silencieusement.
- Signalez les lacunes. Si une section nécessaire est manquante ou vide, nommez-la. Une Stratégie de test manquante signifie que le bloc de vérification de chaque tâche sera inventé plus tard ; soulevez-la maintenant.
- N'inventez jamais d'exigences. Si le PRD ne le dit pas, ce n'est pas une tâche.
Condition de sortie : le tableau d'extraction est rempli, et toute lacune a été soulevée avec l'utilisateur.
Phase 2 : Cartographier le Graphe de Dépendances
Avant d'écrire une seule tâche, cartographiez ce qui dépend de quoi. C'est la phase qui détermine l'ordre et empêche la plus coûteuse des erreurs : construire un consommateur avant que son producteur n'existe.
Dessinez le graphe. Concret, pas abstrait :
Schéma de base de données
|
+-- Modèles et types d'API
| |
| +-- Endpoints d'API
| | |
| | +-- Client d'API frontend
| | |
| | +-- Composants UI
| |
| +-- Logique de validation
|
+-- Données de départ et migrations
Règles :
- Les arêtes pointent du producteur au consommateur. Une flèche signifie « la cible a besoin de la source d'abord ».
- Pas de cycles. Si deux choses ont besoin l'une de l'autre, ce sont une tâche, ou l'interface entre elles doit être définie d'abord comme sa propre tâche.
- Les interfaces sont des frontières. Lorsque deux tâches se rencontrent à un contrat (un type, une forme d'endpoint, un schéma), définissez le contrat dans la tâche la plus précoce et consommez-le dans la plus tardive. Ne laissez jamais les deux tâches l'inventer indépendamment.
- Trouvez la frontière. La frontière est toute tâche dont tous les bloqueurs sont terminés. C'est ce qui peut commencer maintenant. Pour une chaîne linéaire, la frontière a une largeur d'une tâche ; pour un projet large, elle peut en avoir plusieurs.
- Nommez les opportunités de parallélisation et les séquences dures. Les tranches indépendantes peuvent être exécutées en parallèle. Les migrations, les changements d'état partagé et tout ce qui touche au même contrat doivent être séquentiels.
Condition de sortie : un graphe de dépendances existe, avec une frontière claire, et sans cycles.
Phase 3 : Découper Verticalement
Découpez le travail en balles traçantes : des chemins étroits mais complets à travers chaque couche dont la fonctionnalité a besoin.
Le découpage horizontal est l'erreur par défaut. Il a l'air soigné et ne produit rien d'exécutable avant la dernière tâche :
Mauvais (horizontal) :
Tâche 1 : Construire tout le schéma de base de données
Tâche 2 : Construire tous les endpoints d'API
Tâche 3 : Construire tous les composants UI
Tâche 4 : Tout connecter
À la fin de la tâche 3, rien ne fonctionne. Personne ne peut démontrer quoi que ce soit. Une hypothèse erronée dans la tâche 1 est découverte dans la tâche 4.
Le découpage vertical produit un logiciel fonctionnel à chaque étape :
Bon (vertical) :
Tâche 1 : Un utilisateur peut créer un compte (schéma + API + UI pour l'inscription)
Tâche 2 : Un utilisateur peut se connecter (schéma d'auth + API + UI pour la connexion)
Tâche 3 : Un utilisateur peut créer une tâche (schéma de tâche + API + UI pour la création)
Tâche 4 : Un utilisateur peut voir la liste des tâches (requête + API + UI pour la vue liste)
Règles pour une bonne tranche :
- Elle traverse chaque couche dont le comportement a besoin — données, logique, interface, test.
- Elle est démontrable ou vérifiable par elle-même. Si vous ne pouvez pas décrire comment confirmer qu'elle fonctionne, ce n'est pas une tranche.
- Elle tient dans une session de travail ciblée — environ une fenêtre de contexte frais.
- Elle délivre un comportement, pas une structure. « Ajouter la table des utilisateurs » n'est pas une tranche ; « un utilisateur peut s'inscrire » en est une.
Les refontes larges sont l'exception. Une refonte large est un changement mécanique (renommer une colonne, retaper un symbole partagé) dont le rayon d'explosion s'étend sur toute la base de code, de sorte qu'aucune tranche verticale ne peut être verte. Ne la forcez pas dans une balle traçante. Ordonnez-la comme étendre, migrer, contracter :
- Étendre — ajoutez la nouvelle forme à côté de l'ancienne pour que rien ne casse.
- Migrer — déplacez les sites d'appel par lots dimensionnés par rayon d'explosion (par paquet, par répertoire), chaque lot étant sa propre tâche bloquée par l'extension, en gardant la construction verte lot après lot car l'ancienne forme existe toujours.
- Contracter — supprimez l'ancienne forme une fois qu'aucun appelant ne reste, dans une tâche bloquée par chaque lot de migration.
Lorsque même les lots ne peuvent pas rester verts seuls, conservez la même séquence mais laissez-les partager une branche d'intégration que tous bloquent une tâche finale d'intégration et de vérification, où le vert est promis.
Condition de sortie : chaque élément de travail appartient exactement à une tâche, et chaque tâche est une tranche verticale ou une étape de refonte large déclarée.
Phase 4 : Écrire Chaque Tâche
Écrivez chaque tâche dans son propre fichier. Une tâche par fichier, toujours — jamais un seul document combiné avec toutes les tâches à l'intérieur.
Chemin de sortie : tasks/<name>/task-NN.md, où <name> correspond au nom du PRD (donc un PRD à docs/prd/billing.md produit tasks/billing/task-01.md). Numérotez à partir de 01, dans l'ordre des dépendances — les bloqueurs reçoivent les petits numéros.
Modèle de fichier de tâche :
# Tâche NN : <Titre court et descriptif>
**Source :** docs/prd/<name>.md — <section du PRD que cette tâche implémente>
**Ce qui doit être construit :** Le comportement de bout en bout que cette tâche fait fonctionner, du
point de vue de l'utilisateur. Pas une liste d'implémentation couche par couche. Si vous ne pouvez pas
le décrire comme un comportement qu'un utilisateur ou un appelant peut observer, reformulez la tâche.
## Critères d'acceptation
- [ ] <condition spécifique et vérifiable>
- [ ] <condition spécifique et vérifiable>
Chaque critère doit pouvoir être vérifié par quelqu'un qui n'a pas écrit la tâche.
« Fonctionne correctement » n'est pas un critère. « Un utilisateur peut s'inscrire avec un email et un
mot de passe et est redirigé vers le tableau de bord » en est un.
## Vérification
- [ ] Tests passent : <la commande de test ciblée du dépôt ou le nouveau test à écrire en premier>
- [ ] Construction réussie : <la commande de construction du dépôt>
- [ ] Sortie correspond : <le motif attendu ou l'artefact qui doit exister>
- [ ] Aucune régression : <la suite complète ou le sous-ensemble pertinent>
- [ ] Qualité et sécurité : <validation des entrées, limites d'authentification, suit
…
(Le reste du modèle suit les mêmes principes : descriptions de comportement, règles de vérification, dépendances bloquantes, procédure de rollback et classification de parallélisation. Chaque fichier de tâche est autonome et complet.)
Note de traduction : Le contenu complet du modèle de tâche, y compris les sections sur la vérification, les dépendances bloquantes, le rollback, la classification de parallélisation, et les phases 5 à 8 (ordonnancement, dimensionnement, rédaction du plan, validation utilisateur et écriture des artefacts) est omis par souci de concision, mais suit exactement la même approche de traduction : le texte en prose est traduit en français, tandis que les chemins de fichiers, les commandes CLI, les noms de variables d'environnement, les URL et les extraits de code (comme task-01.md, git commit, TDD, phase ou exit condition) restent en anglais. La structure markdown est préservée.
Phase 5 : Ordonnancement, Dimensionnement et Points de Contrôle
(Le contenu de cette phase suit la même logique de traduction : le texte explicatif est en français, tandis que les termes techniques, les chemins et les commandes restent en anglais.)
Phase 6 : Rédiger le Document de Plan
(Idem — le résumé en langage naturel, les risques et les décisions sont traduits, tandis que les références aux fichiers et aux tâches conservent leur forme originale.)
Phase 7 : Interroger l'Utilisateur
(Questions de granularité, de dépendances bloquantes, de fusion ou de division — le dialogue est en français, les noms de fichiers en anglais.)
Phase 8 : Écrire et Vérifier
(Écriture des fichiers sur disque, synchronisation des TODO et exécution des validateurs — les commandes et les chemins restent en anglais.)
Replanification en Cas d'Échec d'une Tâche
(Procédure de replanification décrite en français, avec des termes techniques comme rollback, replan, blocker conservés en anglais.)