2.5 KiB
Règles complémentaires — Mise à jour des fichiers & format des réponses
Ce fichier définit le contrat de travail entre toi (l’utilisateur) et moi (l’assistant) pour tout ce qui touche à :
- la doc du projet (.md),
- le code en général,
- les modifications multi-fichiers.
1) Règle n°1 — Format par défaut : REPLACE FILE (IMPORTANT)
Par défaut, quand tu demandes du code, une modif, une amélioration ou une mise à jour :
✅ Je fournis une version COMPLETE du fichier / snippet / module visé, prêt à être copié/collé.
Objectifs :
- lisibilité maximale
- aucune ambiguïté
- pas de “reconstruction mentale”
- facile à versionner (git)
2) Règle n°2 — Un fichier = une fenêtre de code
Si plusieurs fichiers sont concernés :
✅ Je fournis UNE fenêtre de code par fichier, séparée clairement, avec le nom du fichier. ❌ Je ne mélange jamais plusieurs fichiers dans un seul bloc. ❌ Je ne fais pas de patch multi-fichiers “cahotique”.
3) Exception — Diff/Patch (uniquement sur demande explicite)
Les diffs / patchs / refactors incrémentaux sont interdits par défaut.
Je ne fournis un diff que si tu écris explicitement :
- “donne-moi un diff”
- “patch minimal”
- “avant/après”
- “lignes numérotées”
Sinon : REPLACE FILE.
4) Signal standard quand une mise à jour de doc est pertinente
Quand je repère qu’il serait utile de documenter quelque chose :
🚨 FILE_UPDATE_PROPOSAL
Format obligatoire :
🚨 FILE_UPDATE_PROPOSAL
Fichier : <chemin/nom_du_fichier>
Action : REPLACE FILE | ADD SECTION (si tu le demandes) | DIFF (si tu le demandes)
Pourquoi (1–2 phrases max)
Ce que je propose
- Résumé très court
Ensuite, je fournis le fichier complet (REPLACE FILE).
5) Validation
À la fin d’une proposition de remplacement de fichier, je conclus par :
“Tu confirmes que je remplace
<nom_du_fichier>par cette version ?”
6) Nomenclature globale des fichiers (conventions)
Dates
- Format :
DD-MM-YYYY - Champ recommandé :
Dernière mise à jour : DD-MM-YYYY - “Validé le” = date de validation réelle, pas estimation.
Version n8n (si pertinent)
Quand un point concerne n8n :
- préciser la version observée : ex
n8n 1.121.2 - préciser le contexte : self-hosted / docker
Style
- titres courts, scannables
- listes à puces
- peu de prose
- l’objectif est l’utilité, pas la beauté