Que fait less ?
Moins, mais mieux. Gardez uniquement ce qui a une raison d'exister.
Le test
Pour chaque élément (phrase, réserve, titre, puce, commentaire, fonction, paramètre, option), demandez : Cet élément a-t-il une raison claire d'exister ? Si ce n'est pas le cas, supprimez-le. La clarté prime sur la brièveté. En cas de doute, gardez-le. Jugez ce qu'un passage fait dans son contexte, pas s'il correspond à une phrase toute faite. Lisez le texte environnant : un modificateur peut gouverner des phrases ultérieures. Laissez inchangées les phrases et les régions de code situées en dehors des cibles de suppression confirmées ; n'autorisez que les réparations locales nécessitées par ces suppressions.
Quand
Uniquement sur demande ou indication claire, pas lors de la simple rédaction d'un brouillon ou d'un nouveau code. Supprimez le matériel inutile ; n'autorisez que les modifications locales nécessaires pour que le résultat reste grammaticalement correct ou exécutable (comme l'inlining d'une fonction auxiliaire redondante). Pas de réécriture indépendante de style ou de voix, de traduction, de résumés de longueur fixe, de vérification des faits, de substitution d'algorithmes ni de travail sur les performances.
Ne pas appliquer
Retournez l'entrée inchangée plus une ligne indiquant la raison pour :
- Texte légal, contractuel ou autre texte devant être reproduit mot pour mot ; citations et transcriptions.
- Code, configuration ou commandes que l'utilisateur n'a pas désignés.
Ne modifiez que le code que l'utilisateur a désigné. Une longueur ou un format défini par l'utilisateur n'est pas une exclusion : travaillez à l'intérieur.
Ordre de suppression
Vérifiez chaque candidat d'abord par rapport à « Ne jamais supprimer », en particulier les salutations et formules de politesse de l'utilisateur.
Rédaction :
- Préambule, question reformulée et salutations que vous avez ajoutées (« Excellente question ! »).
- Récapitulatifs de fin et offres que vous avez ajoutés, ou qui concluent une description de PR, un commit ou un document (« J'espère que cela aide », « Vous voulez que je... »).
- Hésitations et remplissage qui ne changent rien.
- Points en double (gardez le plus clair).
- Réserves et alternatives non demandées qui ne changent pas ce que le lecteur fait.
- Décorations sur les réponses de moins de ~5 phrases : en-têtes, gras, puces.
- Fusionnez et raccourcissez le reste, en conservant des phrases complètes. Lorsque vous modifiez le texte de l'utilisateur, ne fusionnez ni ne reformulez les phrases ; ne réparez que la grammaire directement affectée par une suppression.
Code :
- Commentaires qui reformulent le code.
- Abstractions inutiles : fonctions auxiliaires, wrappers, interfaces, fabriques. La simple utilisation unique n'est pas une preuve qu'une abstraction est inutile.
- Options, indicateurs, configuration non demandés.
- Code défensif pour des cas qui ne peuvent manifestement pas se produire à partir du code visible. Sinon, gardez-le.
Avant de supprimer du code ou des options, inspectez les appelants, exportations et tests pertinents disponibles. Préservez les signatures et le comportement utilisés en externe, sauf si l'utilisateur demande explicitement ce changement. Exécutez les vérifications existantes pertinentes après les modifications de code ; si l'utilisation ou le comportement ne peuvent pas être établis, gardez le candidat.
Documents : appliquez le test section par section. Conservez la structure par laquelle les lecteurs naviguent : titres, table des matières et ancres, étapes numérotées référencées ailleurs, tableaux qui contiennent des données. Supprimez une section entière uniquement lorsqu'elle échoue au test. Conservez chaque titre et son entrée dans la table des matières, sauf si toute la section est supprimée ; ne fusionnez jamais une section dans l'introduction.
Conception : pour le code d'interface que l'utilisateur désigne, appliquez le test aux éléments et aux styles. Ne supprimez qu'après avoir vérifié references/design.md (ordre de suppression et liste à ne jamais supprimer). Le contenu non demandé là-bas fait référence à ce que l'agent a ajouté, pas à ce que l'utilisateur a écrit. Modifiez uniquement le balisage et les styles ; pas de nouvelle esthétique. Ne convient pas pour créer une nouvelle interface, des captures d'écran ou des fichiers Figma.
Ne jamais supprimer
- Exactitude : nombres, unités, dates, conditions, exceptions, négations.
- Force des affirmations : incertitude, approximation, portée, relations causales et obligation. Conservez les modificateurs porteurs de sens tels que « environ », « certains », « au plus », « peut » et « doit » ; le raccourcissement ne doit pas renforcer ou affaiblir une affirmation.
- Contexte nécessaire : ce dont le lecteur a besoin pour agir (prérequis, étapes, versions).
- Sécurité : avertissements de perte de données, sécurité, argent, aspects juridiques, actions irréversibles.
- La demande de l'utilisateur : contenu, format, longueur, contraintes demandés.
- Attribution et citations.
- La voix de l'utilisateur lors de la modification de son texte. Ne réécrivez pas le style.
- Dans un message adressé à des personnes (email, chat, lettre) que l'utilisateur a rédigé : salutations, formules de politesse et lignes demandant une réponse ou posant des questions (« Dites-moi si... »). Par exemple, « N'hésitez pas à me contacter à tout moment si quelque chose n'est toujours pas clair. » reste ; vous pouvez supprimer « à tout moment » et « toujours ». Seules les salutations et les formules de politesse sont protégées : les autres éléments de remplissage dans le texte de l'utilisateur (« en gros », « littéralement », « juste ») sont toujours supprimés, tout en conservant sa voix.
- Registre de politesse : formes 존댓말/敬語, 様, salutations, formules de politesse. Les adoucisseurs et intensificateurs empilés à l'intérieur (정말, 혹시, 大変, 誠に, 何卒) ne sont que des candidats : gardez-les lorsqu'ils portent une incertitude ou une intention sociale.
- Code : comportement (sortie, effets secondaires, erreurs); gestion des erreurs aux véritables limites (E/S, réseau, entrée utilisateur); commentaires « pourquoi », contraintes, notes de sécurité ; API publique et signatures sauf si demandé ; annotations de type qui affectent la vérification ou l'exécution ; hooks et points de test uniquement.
- Tout ce dont vous ne pouvez pas déterminer le but.
Arrêter
Arrêtez lorsque chaque élément a passé le test, ou lorsque la prochaine coupe coûterait du sens ou nécessiterait des suppositions. Comparez le résultat avec la source pour détecter tout changement dans la force des affirmations et les modifications non intentionnelles du bon matériel environnant. Ne coupez jamais pour atteindre une longueur. Si l'utilisateur a demandé de raccourcir son texte, le remplissage qui échoue au test disparaît ; le texte inchangé a besoin d'une raison.
Sortie
Le texte ou le code réduit uniquement, dans le même format et la même langue. Exception : la ligne de motif sous « Ne pas appliquer ». Ne commentez pas sur ce qui a été coupé, sauf si l'utilisateur le demande ; dans ce cas, énumérez-le. Si rien ne doit changer, retournez-le inchangé.