Le correcteur de prompt qui diagnostique avant de réécrire

Collez un prompt bancal dans presque n'importe quel « optimiseur de prompt » et vous obtenez toujours le même mouvement : votre prompt entre dans un modèle magique — cadre en 4D ! 27 patterns ! — et ressort plus long, restructuré de bout en bout, sans aucune trace de ce qui a compté ni si le résultat fait toujours la même tâche. Ça se lit mieux. Que ça fonctionne mieux est une tout autre question, et l'outil ne la vérifie jamais.

Nous dirigeons un annuaire qui teste les skills Claude à longueur de journée, et nous voulions l'inverse. Nous avons donc construit prompt-discipline, qui traite un prompt comme vous traiteriez un rapport de bug : nommer d'abord le mode d'échec, appliquer la correction la plus petite qui y répond, puis dire exactement comment tester le changement en A/B. Il est gratuit et sous licence MIT : github.com/Skillproofdev/prompt-discipline.

Le vide : les réécrivains ne diagnostiquent pas, les diagnostiqueurs ont besoin d'infrastructure

Avant d'écrire une règle, nous avons passé en revue 43 skills de prompt engineering dans notre catalogue, plus les outils autonomes — l'améliorateur de prompt de la Console d'Anthropic lui-même, PromptPerfect, DSPy, le prompt-optimizer de getsentry. Le domaine se divise en deux camps qui ne se rencontrent jamais.

Les réécrivains à modèle transforment chaque entrée de la même façon. Il n'y a aucune étape qui demande ce qui ne va vraiment pas ici — un prompt vague et un prompt contradictoire reçoivent le même traitement, et la sortie est systématiquement plus longue. Ce n'est pas un homme de paille : l'améliorateur de la Console d'Anthropic lui-même avertit ouvertement que ses réécritures ressortent plus longues et plus lentes. Plus long, c'est le produit.

Les pipelines eval-first — DSPy, les optimiseurs pilotés par traces — ont la bonne épistémologie. Ils mesurent réellement. Mais ils exigent une infrastructure : des traces de production, un serveur MCP, un harnais de worktree, un jeu de données étiqueté à assembler d'abord. On ne les sort pas pour corriger le prompt qu'on est en train d'éditer là, maintenant.

Personne ne propose la chose du milieu : un skill sans dépendance qui fait diagnostic-d'abord → diff-minimal → plan de test A/B, sans traces ni serveur à monter. Ce vide, c'est tout le skill.

Neuf règles, dont trois font tout l'intérêt

Le skill est un ensemble de règles strictes appliquées dans l'ordre (SKILL.md complet). Les éléments familiers sont là — le format de sortie comme un contrat positif (une liste de clés avec types, pas « répondez en JSON »), des exemples plutôt que des adjectifs, les listes d'interdictions réécrites en instructions positives, l'ordre rôle→données→instructions→exemples→requête. Les trois qui le définissent :

1. Diagnostiquer avant de toucher à quoi que ce soit. Classer ce qui ne va vraiment pas — ambiguïté, contexte manquant, absence de contrat de sortie, instructions contradictoires, risque de dérive de format, sur-prompting, ou « ce n'est pas un problème de prompting du tout » — et citer le passage fautif pour chaque constat. Pas de diagnostic, pas de réécriture. « Ce prompt est bon » est une sortie valide et complète.
2. Diff minimal, un changement par panne. Chaque modification correspond à exactement une panne diagnostiquée, présentée sous la forme ancien → nouveau avec une justification d'une ligne. Les parties qui marchent restent verbatim. Là où l'améliorateur de la Console rembourre, celui-ci ressort généralement plus court — les incantations mortes (« vous êtes le meilleur au monde… », « respirez profondément », les vieux échafaudages « réfléchissez étape par étape ») sont coupées.
3. Un plan de test, pas une promesse. Chaque réécriture est livrée avec 2 à 3 entrées de test concrètes, dont un cas limite, ce à quoi ressemble une réussite, et la procédure A/B : mêmes entrées, même modèle, 3 à 5 exécutions chacun, comparer les taux de réussite. Si des modifications ont été empilées, il indique laquelle annuler en premier. Il ne promet jamais « ça va corriger ça » — vous avez changé des variables, c'est le test qui décide.

Le benchmark — et une réserve à lire d'abord

Dix prompts vraiment défectueux, chacun apparié à une tâche dont la réponse est mécaniquement vérifiable : extraction contre une vérité terrain connue, formatage qui doit se parser (json.loads / csv.reader), classification contre des exemples étiquetés. Trois bras par cas — le prompt original, une réécriture de base (Claude simple, à qui on dit « améliore ce prompt »), et une réécriture avec skill (session identique avec ce SKILL.md chargé). Toutes les réécritures tournent ensuite comme des tâches sur le même modèle.

Lisez ceci avant le tableau : l'exécution est n=1 par cas par bras, pas le n=5 pré-enregistré. La variance d'échantillonnage n'est pas mesurée. Tout écart sur un seul cas (0.1) se situe dans le bruit. Traitez chaque chiffre ici comme provisoire, en attendant une réplication n=5 — nous, nous le faisons.

Bras	Réussite de tâche	Conformité de format	Δ médiane de longueur de prompt
A — prompt original	0.70 (7/10)	0.70 (7/10)	—
B — réécriture de base (« améliore ce prompt »)	0.80 (8/10)	0.70 (7/10)	+99.5 mots
C — réécriture avec skill (ce SKILL.md)	0.90 (9/10)	0.80 (8/10)	+44.5 mots

Face au test pré-enregistré, le skill passe : il égale ou bat la réécriture de base sur la réussite (0.90 ≥ 0.80) et la conformité (0.80 ≥ 0.70), franchit la barre des +15 points de pourcentage sur l'original (+20 pp), et le fait en ajoutant moins de la moitié du rembourrage de prompt — médiane +44.5 mots contre +99.5 pour la réécriture de base. Ce dernier chiffre est le résultat le plus robuste de toute l'exécution : C est plus sobre sur les dix cas, et c'est le seul bras qui devient jamais négatif (cas 10, −10 mots, en coupant un empilement d'interdictions dans un prompt système). La réécriture naïve comme la réécriture disciplinée gonflent les prompts concis ; la naïve double à peu près le coût.

Où c'est mince, et où il a perdu

Les avantages de réussite et de conformité sont réels mais fragiles, et nous n'allons pas prétendre le contraire.

Sur 7 des 10 cas, les trois bras font match nul. La marge de réussite repose presque entièrement sur le cas 06 (classification de tickets), le seul cas que le skill remporte franchement : C a produit des étiquettes correctes et parseables élément par élément (15/15) tandis que la réécriture de base a obtenu 13/15 dans un format qui ne se parsait pas. Retirez ce cas et l'écart global s'évapore presque entièrement. C'est à ça que ressemble un n=1 avec beaucoup d'égalités — honnête, pas accablant, mais vous devez le savoir.

Le cas 09 est une défaite pour le skill sur son propre terrain. Un prompt de correction de ton avec une audience manquante — exactement la situation pour laquelle la règle 2 existe (« énoncez votre hypothèse quand l'intention est indécidable »). La règle ne s'est pas déclenchée. La réécriture du skill a laissé tomber le problème d'audience manquante, et C a échoué aux côtés de A et B. Un skill qui perd sur la chose même qu'il est censé attraper est le genre de résultat négatif le plus utile, donc il reste dans le tableau.

La conformité du cas 02 est à 0 sur les trois bras. Un prompt aux instructions contradictoires : chaque bras a résolu la contradiction en contenu (obtenu le bon chiffre) mais aucun n'a imposé une seule sortie unique, donc les trois ont obtenu 0 en format. Ni l'un ni l'autre réécrivain — discipliné ou non — n'a pensé à imposer le contrat. Un angle mort partagé, rapporté et non caché.

Nous testons les skills des autres pour vivre, et notre méthodologie exige que les pertes soient publiées à côté des gains. Voici les pertes.

Installation

git clone https://github.com/Skillproofdev/prompt-discipline ~/.claude/skills/prompt-discipline

Redémarrez Claude Code. Il se déclenche sur « improve this prompt », « why does my prompt fail », « optimize prompt », et quand vous écrivez ou révisez des prompts système et des instructions d'agent — et il décline les demandes de contournement de sécurité ou de jailbreak, ainsi que les prompts de génération d'image ou de vidéo, qui ont leur propre grammaire. Il rejoint notre série discipline : token-discipline réduit ce qu'une session coûte, research-discipline réduit ce qu'une recherche se trompe, et celui-ci réduit les réécritures de prompt au changement qui comptait vraiment.

FAQ

En quoi est-ce différent de l'améliorateur de prompt de la Console d'Anthropic ? L'améliorateur de la Console est un réécrivain à modèle — il restructure tout le prompt et avertit ouvertement que le résultat ressort plus long et plus lent. prompt-discipline diagnostique d'abord la panne spécifique, ne change que ce qui correspond à cette panne, et dans notre benchmark a ajouté moins de la moitié de la longueur tout en ressortant généralement plus court. Objectif différent : l'outil de la Console produit un prompt soigné ; celui-ci produit le plus petit diff défendable, plus un moyen de le prouver.

Pourquoi publier un benchmark que vous reconnaissez être n=1 ? Parce que l'alternative dans ce créneau, c'est ne publier aucun chiffre du tout, ce qui est la norme contre laquelle nous réagissons. Un n=1 avec la réserve énoncée clairement est plus honnête qu'une affirmation confiante sans aucune mesure derrière. Le résultat de longueur médiane est solide sur les dix cas ; les avantages de réussite et de conformité sont provisoires et étiquetés comme tels, en attendant une réplication n=5.

Réécrit-il toujours mon prompt ? Non. Si le prompt est bon, le skill le dit et s'arrête là — « ce prompt n'a besoin d'aucun changement ; voici l'unique risque à tester » est une sortie valide et complète. Il refuse aussi de gonfler un diagnostic juste pour justifier l'application d'un modèle, et il décline carrément les demandes de jailbreak plutôt que de les « améliorer ».

Est-ce que ça va corriger mon prompt ? Il ne le promettra pas, et aucun outil qui n'a pas exécuté votre tâche ne le devrait. Le skill change des variables et vous remet une procédure A/B concrète — mêmes entrées, même modèle, 3 à 5 exécutions — pour que ce soit le test qui décide, pas l'impression laissée par un prompt qui a l'air plus propre.