AgentDock

Lisez les directives de développement pertinentes avant de commencer votre tâche.

Exécutez ces étapes :

1. Lire les artefacts de la tâche en cours :

   • prd.md pour les exigences et les critères d'acceptation
   • design.md s'il est présent pour la conception technique
   • implement.md s'il est présent pour l'ordre d'exécution et le plan de validation

2. Découvrir les packages et leurs couches de spécifications :

   python3 ./.trellis/scripts/get_context.py --mode packages
   

3. Identifier les spécifications applicables à votre tâche en fonction :

   • Du package que vous modifiez (par ex., cli/, docs-site/)
   • Du type de travail (backend, frontend, test-unitaire, documentation, etc.)
   • Des chemins de spécifications/recherche référencés par les artefacts de la tâche

4. Lire l'index de spécifications pour chaque module pertinent :

   cat .trellis/spec/<package>/<couche>/index.md
   

   Suivez la section "Liste de vérification pré-développement" dans l'index.

5. Lire les fichiers de directives spécifiques listés dans la Liste de vérification pré-développement qui sont pertinents pour votre tâche. L'index n'est PAS l'objectif — il vous oriente vers les fichiers de directives réels (par ex., error-handling.md, conventions.md, mock-strategies.md). Lisez ces fichiers pour comprendre les standards et patterns de codage.

6. Toujours lire les guides partagés :

   cat .trellis/spec/guides/index.md
   

7. Pour une tâche non triviale, énoncez le périmètre du changement avant d'écrire du code. Non triviale signifie qu'elle touche plus d'un fichier, traverse une couche, modifie une interface publique, ou édite du code que vous n'avez pas écrit récemment. Écrivez :

   • le plus petit écart de comportement entre ce qui se produit maintenant et ce qui devrait se produire
   • où réside réellement ce comportement (pas là où il est le plus facile d'intervenir)
   • quels fichiers vous prévoyez de modifier, et pourquoi chacun est nécessaire
   • ce que vous ne ferez explicitement PAS dans cette tâche
   • si un refactoring local est nécessaire, comment vous montrerez qu'il n'a pas changé le comportement

   Un changement petit et bien délimité n'en a pas besoin — faites-le directement.

   Si le périmètre réel s'avère clairement plus large que cela, dites-le et expliquez pourquoi avant de continuer. N'élargissez pas le changement par vous-même.

8. Comprenez les standards et patterns de codage que vous devez suivre, puis poursuivez avec votre plan de développement.

Cette étape est obligatoire avant d'écrire du code.