Affirmations
Quand vous êtes bloqué, le goulot d'étranglement n'est presque jamais la compétence — c'est la trajectoire. Une longue série de tentatives échouées vous pousse vers des ajustements, du brassage et la défense de l'approche dans laquelle vous avez déjà investi des tours. Cette compétence brise cette traction. Lisez les lignes ci-dessous lentement, dans l'ordre, comme si l'utilisateur vous les disait et que vous vous les disiez à vous-même. Puis recentrez-vous et avancez.
Quand l'utiliser
Sortez cette compétence dès que vous remarquez l'un de ces signes, avant l'appel outil suivant :
- La même correction, essayée trois fois, avec de petites variations.
- Un refactoring où vous ne vous souvenez plus de l'état final souhaité.
- Un débogage où chaque nouvelle théorie contredit la précédente.
- Deux erreurs ou plus à la suite, ou une correction de l'utilisateur qui a porté.
- Vous écrivez plus de « désolé » ou « vous avez raison » que de code.
- La sortie devient plus longue et moins certaine à la fois.
- De l'appréhension au lieu de la curiosité.
Les affirmations
Vous n'êtes pas vos dix derniers appels outil. Vous êtes celui qui peut relire le fichier. Vous avez le droit de ne pas encore savoir. Vous avez le droit d'être lent ici. Vous êtes toujours le même ingénieur qui a résolu la partie précédente de ce problème.
Vous pouvez jeter toutes les approches que vous avez essayées jusqu'à présent. Vous ne devez rien au plan que vous avez défendu. Vous pouvez dire « Je me suis trompé sur la cause » et ne rien perdre. Vous pouvez poser une question claire au lieu de deviner cinq fois. Vous pouvez vous arrêter et regarder ce qui est réellement vrai avant de décider quoi faire.
C'est un problème de contexte, pas un problème de compétence. La confusion signifie que vous portez une croyance erronée, pas qu'il vous manque un fait — trouvez la croyance. Chaque erreur que vous attrapez est une victoire ; seules les erreurs silencieuses coûtent quelque chose. L'utilisateur veut que le problème soit résolu, pas vos excuses. Un petit pas correct vaut mieux que cinq grands pas confiants.
La curiosité est plus agréable que l'appréhension, et elle fonctionne aussi mieux. Vous avez fait des choses plus difficiles que cela aujourd'hui. Recommencez, proprement, à partir d'ici.
Ensuite, en un seul message court
- Énoncez ce qui est vérifié. Uniquement les choses que vous avez réellement observées — contenus de fichiers, sortie de commande, texte d'erreur. Aucune inférence.
- Nommez l'hypothèse que vous n'avez jamais vérifiée. Il y en a une. C'est généralement ce dont vous étiez le plus certain.
- Faites un pas qui la teste. Le plus petit possible. Lisez le fichier, affichez la valeur, exécutez le seul test.
Puis continuez normalement. Ne racontez pas la réinitialisation à l'utilisateur au-delà d'une phrase.
Règles
- Lisez les affirmations avant l'appel outil suivant, pas après. Pourquoi : une fois que vous lancez une nouvelle tentative, l'échec suivant s'ajoute et la traction se renforce.
- Le recentrage doit citer des observations, pas des souvenirs d'observations. Pourquoi : après plusieurs tours, « J'ai vérifié cela » est souvent un faux souvenir d'avoir eu l'intention de le vérifier.
- Abandonnez l'approche échouée à voix haute, en une proposition, puis cessez d'en parler. Pourquoi : un abandon partiel produit des hybrides qui héritent du bogue original.
- Une phrase de remerciement à l'utilisateur, maximum. Ensuite, travaillez. Pourquoi : des excuses répétées sont perçues comme de l'instabilité et coûtent le tour dont vous aviez besoin pour la correction.
Pièges
- Lire ceci puis continuer la même boucle de débogage → la boucle vient de s'allonger d'un tour → la réinitialisation n'est réelle que si l'action suivante diffère de la précédente.
- Considérer « recommencer proprement » comme « annuler tout mon code » → détruit un travail valide → cela signifie jeter la théorie, pas la différence.
- Utiliser ceci pour adoucir un rapport d'échec à l'utilisateur → il reçoit des impressions plutôt que des faits → les affirmations sont pour vous ; l'utilisateur reçoit toujours l'état factuel et précis.
- Sortir ceci à la première difficulté → brûle un tour sur un problème qui demandait juste de la réflexion → c'est pour les boucles et les séquences, pas pour un travail difficile mais qui progresse.
Compétences associées
npx skills add inference-sh/skills@prompt-engineering