moyu-strict

Aperçu du skill moyu-strict

Ce qu’est moyu-strict

moyu-strict est un skill de garde-fou pour l’édition de code qui impose une discipline stricte contre la sur-ingénierie. Il est conçu pour les situations où vous voulez la modification la plus petite possible et sans risque, pas une refonte soignée. Son rôle principal est d’empêcher un agent de toucher des fichiers supplémentaires, d’ajouter des abstractions ou « d’améliorer » du code sans rapport, tout en répondant quand même à la demande.

À qui il s’adresse

Ce skill moyu-strict convient particulièrement aux relecteurs, aux maintainers et aux agents qui travaillent sur des correctifs très ciblés dans des bases de code existantes. Si vous tenez aux diffs minimaux, à une revue prévisible et à l’évitement des effets de bord accidentels, moyu-strict for Code Editing est un excellent choix. Il est moins utile pour les refactorings exploratoires, les travaux d’architecture ou les grands chantiers de nettoyage.

Ce qui le distingue

La différence pratique, c’est l’application stricte des règles. moyu-strict n’est pas un prompt générique du type « écris un meilleur code » ; il met l’accent sur la maîtrise du périmètre, la discipline de modification et la retenue. Ses signaux les plus forts sont ses règles explicites : confirmer le périmètre avant de modifier, éviter les nouveaux niveaux d’abstraction, ne pas ajouter de documentation, de tests ou de dépendances non demandés, et s’arrêter dès qu’un changement devient trop important par rapport à la demande.

Comment utiliser le skill moyu-strict

L’installer et l’activer

Suivez le flux d’installation du repo pour moyu-strict install, puis chargez-le lorsque vous anticipez des modifications de code qui doivent rester très limitées. Si votre environnement utilise un installateur basé sur des commandes, l’idée clé est d’attacher moyu-strict avant que le modèle commence à éditer, afin que les contraintes façonnent le premier jet et pas seulement la revue. Pour moyu-strict usage, activez-le chaque fois que la tâche est un correctif ciblé, pas une session de conception.

Lire d’abord les bons fichiers

Commencez par skills/moyu-strict/SKILL.md, car c’est là que se trouvent les règles strictes et le comportement d’activation. Comme ce repo ne contient qu’un seul fichier de skill, sans scripts d’assistance, sans références ni dossiers de règles, il n’y a pas d’arborescence cachée à parcourir. Ce qui compte vraiment pour l’utilisateur, c’est le texte des règles lui-même, pas une visite prolongée du dépôt.

Transformer une demande floue en prompt strict

Le skill donne les meilleurs résultats quand la demande nomme déjà la cible exacte et la limite exacte. Un bon prompt ressemble à ceci : « Corrige le crash lié à null dans src/parser.ts et modifie uniquement ce fichier ; n’ajoute ni tests, ni commentaires, ni refactoring. » Un mauvais prompt ressemble à : « Améliore ce module. » Le premier donne à moyu-strict quelque chose à encadrer ; le second ouvre la porte à un débordement de périmètre.

L’utiliser dans un flux de confirmation de modification

Un bon moyu-strict guide ressemble à ceci : identifier le fichier ou la fonction concernée, préciser la modification attendue, confirmer qu’aucun autre fichier ne doit bouger, puis éditer. Si la tâche semble exiger des changements plus larges, il faut s’arrêter et demander si une version plus petite est acceptable. C’est là toute la valeur la plus stricte du skill : rendre le dépassement de périmètre visible avant qu’il ne devienne un diff.

FAQ du skill moyu-strict

Est-ce que moyu-strict n’est qu’un prompt ordinaire ?

Non. Un prompt ordinaire peut demander un code concis, mais moyu-strict vise spécifiquement à imposer des limites d’édition. Il est particulièrement utile quand le principal risque n’est pas une logique incorrecte, mais des modifications supplémentaires inutiles.

Dans quels cas ne faut-il pas l’utiliser ?

N’utilisez pas moyu-strict pour des tâches qui nécessitent réellement une réécriture coordonnée, une nouvelle abstraction, une remise à niveau de la documentation ou la création d’un harness de test. Si le résultat attendu doit inclure un nettoyage plus large, la préférence du skill pour une « PR minimale » peut entrer en conflit avec l’objectif réel.

Est-il adapté aux débutants ?

Oui, parce que les règles sont simples et concrètes. L’erreur la plus fréquente chez les débutants est de formuler une demande vague et d’attendre du skill qu’il devine le périmètre. moyu-strict fonctionne bien mieux quand l’utilisateur peut dire ce qui doit changer et, tout aussi important, ce qui ne doit pas changer.

En quoi diffère-t-il des prompts classiques d’édition de code ?

Les prompts classiques optimisent souvent l’achèvement de la tâche. moyu-strict, lui, optimise la retenue. Il indique à l’agent de contester l’extension du périmètre, d’éviter les changements décoratifs et de garder des diffs assez petits pour être revus rapidement. Cela en fait un meilleur choix pour la maintenance que pour l’extension de fonctionnalités.

Comment améliorer le skill moyu-strict

Préciser la limite exacte de modification

Le plus gros gain de qualité vient du fait de nommer dès le départ le fichier, la fonction et le résultat attendu. Au lieu de dire « nettoie ça », dites : « modifie seulement src/auth.ts pour gérer les jetons vides, et laisse le reste intact. » Cela aide moyu-strict à appliquer la réponse la plus étroite possible.

Dire explicitement ce qui est interdit

Comme moyu-strict repose sur les exclusions, il faut préciser ce qu’il ne faut pas ajouter : pas de nouveaux helpers, pas de commentaires, pas de tests, pas de changements de dépendances, pas de modifications de formatage seules. C’est important, parce que la valeur du skill tient au refus des ajouts inutiles, pas à l’invention d’une solution plus large.

Surveiller le mode d’échec le plus courant

L’échec le plus fréquent, c’est une demande qui commence petit mais qui s’élargit silencieusement en refonte. Dans ce cas, la meilleure amélioration n’est pas « plus de qualité de code » ; c’est de réduire la tâche. Demandez le patch le plus petit acceptable, puis itérez si besoin. Cela maintient le skill moyu-strict aligné sur ses limites strictes de diff et sa philosophie du changement minimal.

Itérer à partir d’un premier patch minuscule

Si le premier résultat est trop large, resserrez le prompt autour d’un seul symptôme, d’un seul fichier et d’un seul résultat. Si le premier résultat est trop superficiel, ajoutez seulement la contrainte manquante la plus importante, par exemple « ne change pas les signatures » ou « ne modifie pas les call sites ». Pour les utilisateurs de moyu-strict skill, de meilleurs résultats viennent généralement de frontières plus nettes, pas d’instructions plus longues.