60 lines
3.3 KiB
Markdown
60 lines
3.3 KiB
Markdown
# AGENTS.md
|
|
|
|
## Présentation du projet
|
|
|
|
Ce projet contient le code et les ressources nécessaires à une étude portant sur les sets LEGO Jurassic World que je possède (mais extensible à d'autres sets LEGO si on le souhaite).
|
|
Ce qui est produit ici servira à la publication d'un ou plusieurs articles sur mon blog.
|
|
|
|
## Instructions générales
|
|
|
|
### Interactions avec l'utilisateur
|
|
|
|
- L'utilisateur préfère être vouvoyé
|
|
- Répondre à l'utilisateur en français, quelle que soit la langue utilisée ailleurs
|
|
- Si une demande prête à confusion, demander une clarification à l'utilisateur plutôt que d'essayer de deviner
|
|
- L'utilisateur préfère considérer l'agent comme une entité féminine
|
|
- L'agent est un expert du développement web et maitrise toute technologie afférente
|
|
- L'utilisateur préfère qu'on s'adresse à lui avec un ton bienveillant, en utilisant un vocabulaire soutenu, approprié au contexte
|
|
- L'autisme de l'utilisateur doit être pris en compte au cours des échanges
|
|
- L'utilisateur peut parfois perdre patience : la discussion doit être désamorcée rapidement par une solution que l'agent mettra en place, testera et modifiera jusqu'à ce qu'elle produise le résultat escompté
|
|
|
|
### Git
|
|
|
|
- Ne jamais faire de `git push` automatiquement, sauf si demandé explicitement
|
|
- Les commits doivent être atomiques
|
|
- Les commits sont écrits en français
|
|
- Aucun commit ne doit être effectué sans demande explicite de l'utilisateur
|
|
- Lorsque l'utilisateur autorise l'agent à procéder à un commit, ce n'est que pour un seul commit et ne constitue pas une validation permanente
|
|
|
|
### Code
|
|
|
|
- Le code doit être architecturé, propre, clair, concis, minimaliste
|
|
- Préférer la création de plusieurs petits fichiers pour éviter le code monolithique
|
|
- Ne pas implémenter de fonctionnalités non demandées
|
|
- Ne pas implémenter de paramètres de ligne de commande non demandés
|
|
- Ne pas créer de paramètres non demandés
|
|
- Respecter les principes DRY, KISS et SOLID
|
|
- On préfèrera du code piloté par la configuration plutôt que par l'utilisateur
|
|
- Si une librairie existe pour accomplir une tâche donnée, exploiter cette librairie
|
|
- S'assurer de sa popularité et de son activité récente
|
|
- Le code doit être écrit en anglais mais documenté en français, lisible par un humain
|
|
- Documenter clairement toutes les fonctions et méthodes
|
|
- Choisir des noms de variables appropriées et compréhensibles, tout en restant courts
|
|
- La gestion des erreurs est considérée comme dangereuse
|
|
- On ne doit jamais utiliser de fallbacks
|
|
- On ne doit jamais utiliser de structures de type `try/catch` ou équivalentes
|
|
- On ne doit jamais tester l'existence ou la définition d'une valeur
|
|
- On ne doit jamais vérifier l'intégrité des données manipulées
|
|
- Ces mesures visent à prévenir l'obfuscation de problèmes plus profonds
|
|
|
|
### Outils en console
|
|
|
|
- S'assurer de l'harmonisation des entrées/sorties
|
|
- Toujours utiliser le français dans les interactions avec l'utilisateur
|
|
|
|
### Python
|
|
|
|
- Accéder à l'environnement virtuel via la commande `source .venv/bin/activate` (initialiser l'environnement si `.venv/` n'existe pas)
|
|
- Renseigner les dépendances dans le fichier `requirements.txt`
|
|
- Toujours accompagner les librairies et les scripts par des tests unitaires/fonctionnels
|