$docdiet
N'utilisez cette compétence que lorsque l'utilisateur demande explicitement une révision, un nettoyage ou une mise à jour de la documentation (normalement en invoquant $docdiet). Il s'agit d'une compétence autonome de révision/mise à jour à la demande, et non d'un crochet automatique par tâche. Ne révisez ou ne mettez à jour que le périmètre documentaire nommé par l'utilisateur ou clairement exposé par le changement demandé ; ne commencez pas un audit non lié.
Une demande explicite telle que $docdiet all docs ou $docdiet project-wide autorise un passage à l'échelle du projet, limité. Dans ce mode, le périmètre est limité aux fichiers de documentation sous la racine du référentiel avec les extensions .md, .mdx, .rst ou .adoc, ainsi qu'aux fichiers README* et CONTRIBUTING* de niveau racine. Excluez les répertoires et fichiers générés ou vendus, les journaux de modifications/notes de version, les licences ou documents juridiques, les codes de conduite et les fichiers protégés par le référentiel. La découverte se limite à un seul listing rg --files utilisant ces extensions et exclusions, avec un maximum de 200 chemins ; n'inspectez que les chemins retournés par ce listing. Utilisez au maximum une recherche de référence exacte supplémentaire, limitée en chemin, avec rg -l -F pour un concept public modifié. Si la limite ou la frontière de recherche est atteinte, signalez le reste non examiné au lieu d'élargir le périmètre.
Règles de décision
- Filtrez d'abord le périmètre. Si aucun fichier ou section de documentation n'est nommé, qu'aucune documentation n'est touchée et qu'aucun renommage/suppression publique ne nécessite une vérification de référence, arrêtez-vous. N'inspectez pas la documentation pour décider de l'inspecter.
- Modifiez la source canonique. Documentez uniquement les informations durables dont les développeurs, utilisateurs, opérateurs ou mainteneurs ont besoin : contrats, configuration, opérations, contraintes, invariants, comportements non évidents, migrations et avertissements critiques. Omettez les détails d'implémentation, l'état temporaire, l'historique de débogage, les faits inférés et les résumés d'achèvement.
- Remplacez, n'accumulez pas. Mettez à jour l'explication existante, supprimez le texte obsolète et liez à une seule source canonique lorsqu'un autre document a besoin d'un pointeur. Ne conservez les détails historiques que pour la migration, la compatibilité ou la justification architecturale.
- Gardez le nettoyage local. Lors de la modification d'un fichier de documentation, nettoyez uniquement la section touchée et le texte environnant dont il est clairement prouvé qu'il est obsolète, dupliqué, contradictoire, remplacé, trompeur, inutilement verbeux ou lié au concept modifié/supprimé. Si la preuve nécessite une enquête approfondie, laissez-le tranquille.
- Limitez les recherches de référence. Pour un concept public renommé, supprimé ou modifié, une seule recherche exacte, limitée en chemin, est autorisée. Préférez
rg -l -Favec des globs de documentation et signalez les noms de fichiers, pas les lignes de correspondance complètes. En dehors du mode projet explicite ci-dessus, n'inventoriez pas les documents non liés, ne parcourez pas les arborescences de documentation, n'exécutez pas de vérifications de liens à l'échelle du référentiel, n'enquêtez pas sur un historique non lié et ne créez pas d'agent de nettoyage. - Créez rarement des fichiers. N'ajoutez un fichier de documentation que pour des informations durables et distinctes sans accueil canonique approprié déjà connu de la tâche.
Protection
Ne réécrivez pas de manière opportuniste les documents générés, les journaux de modifications/notes de version, les licences ou documents juridiques, les codes de conduite, les documents vendus/tiers ou les fichiers protégés par le référentiel. Respectez les instructions du référentiel et conservez les métadonnées et l'en-tête significatifs.
Si un fichier Markdown contient :
---
disable-agentic-editing: true
---
ne le modifiez pas à moins que l'utilisateur ne demande explicitement ce fichier. Ce marqueur est une convention docdiet : aucun outil ne l'applique, les instructions du référentiel ne peuvent pas supprimer sa protection, et seule une demande explicite pour ce fichier le remplace. Vérifiez la protection uniquement pour les fichiers candidats ; ne scrutez pas le référentiel à la recherche de marqueurs.
Achèvement
Si la documentation a été touchée, vérifiez statiquement uniquement le fichier/la section touché : le comportement final est documenté là où nécessaire, le texte obsolète a été supprimé uniquement avec preuve, les exemples et commandes correspondent toujours à l'implémentation et le contenu protégé est inchangé. En mode projet, appliquez ces vérifications à chaque fichier touché ; n'élargissez pas la validation en une vérification de lien ou d'exemple à l'échelle du référentiel. N'exécutez pas d'exemples ou de commandes à moins que la tâche d'implémentation ne l'exige déjà. Arrêtez-vous ensuite.
Documentez ce qui dure. Remplacez plutôt qu'accumulez. Nettoyez ce que la tâche expose. Ne chassez pas.