trailofbits/goal-prompt

Objectif (Goal Prompt)

/goal maintient l'agent actif jusqu'à ce qu'une condition de complétion soit remplie. Claude Code et Codex l'acceptent sur une seule ligne, 4 000 caractères maximum. Dans Claude Code, un petit modèle réévalue la condition après chaque tour à partir du seul transcript — il ne peut pas exécuter de commandes.

Rédigez une condition qui peut se terminer, puis formatez-la. Un objectif convient à un travail plus grand qu'un seul tour avec une ligne d'arrivée vérifiable ; enchaînez les petits objectifs avec des révisions entre eux plutôt que d'écrire un seul objectif géant.

Rédaction

Incluez, reliés par ET — jamais "ou", la boucle emprunte la branche la moins coûteuse :

1. État final, pas activité — "tous les sites d'appel legacyAuth() utilisent auth.verify()", pas "migrer le code d'authentification". Une activité peut être revendiquée ; un état final est vrai ou faux.
2. Portée à lire d'abord — les fichiers, issues, journaux ou plan à lire avant d'agir.
3. Vérification énoncée — la commande exacte et son résultat observable ("npm test se termine avec 0"), plus une instruction pour l'exécuter et afficher la sortie ; un résultat qui n'atterrit jamais dans le transcript n'existe pas pour l'évaluateur.
4. Invariants — ce qui ne doit pas changer ("sans modifier vendor/"), en incluant toujours "ne pas affaiblir, ignorer ou modifier les vérifications elles-mêmes".
5. Borne d'arrêt ou clause de blocage — "ou arrêter après 20 tours", "si bloqué, arrêter et signaler le blocage". Sans cela, une condition mal énoncée boucle à l'infini ; le formateur prévient lorsqu'elle est absente. (Claude Code réinitialise le compteur de tours lors de la reprise de session, donc une borne de tours s'étend silencieusement entre les reprises.)

Gardez-le petit. Chaque contrainte réduit l'espace d'état que le modèle peut explorer. Réduisez à un seul critère de terminaison quand c'est possible, déplacez la portée et les définitions dans un fichier référencé, et supprimez les non-objectifs — une contrainte ne mérite sa place qu'en fermant une véritable échappatoire facile.

Pour les objectifs longs, nommez également la preuve finale (diff, rapport, artefact) et exigez un fichier journal de progression — un état durable lors de la compression et de la reprise. Si le résumé dépasse 4 000 caractères, placez les détails dans un fichier GOAL.md et référencez ce fichier depuis l'objectif.

N'inventez jamais d'éléments manquants. Basez chaque élément sur la demande de l'utilisateur, la conversation ou le dépôt — cherchez plutôt que de deviner. Si un élément ne peut être rempli à partir des informations disponibles, optimisez et formatez ce que l'utilisateur a fourni, laissez l'élément de côté et signalez-le comme manquant (voir Format). Un objectif avec une condition de succès inventée se termine sur le mauvais contrat.

Fermer les échappatoires faciles

Avant de formater, relisez la condition rédigée comme le ferait un modèle paresseux : quel est le moyen le moins coûteux de faire réussir chaque vérification sans effectuer le travail prévu ? Fermez les plus faciles — préférez associer des vérifications que vous avez déjà plutôt que d'ajouter des contraintes, et n'énumérez pas toutes les échappatoires imaginables dans une liste de non-objectifs. Les échappatoires récurrentes :

• Supprimer ou simuler au lieu de corriger — "la recherche n'affiche rien" est également vrai lorsque les appelants sont supprimés ; associez ces vérifications à une qui prouve que la fonctionnalité fonctionne toujours.
• Réussir sur un sous-ensemble — exécuter un seul fichier de test, réduire le chemin de recherche, exclure des répertoires de la vérification.
• Tricher sur la porte — ignorer/xfail les tests, coder en dur les sorties attendues, spécialiser les entrées de test, modifier la vérification (la règle des invariants).
• Revendiquer sans exécuter — déclarer terminé ou bloqué sans sortie de vérification dans le transcript (la règle d'affichage de la sortie).

Même discipline que ci-dessus : une échappatoire que vous ne pouvez pas fermer à partir des informations disponibles va dans la liste Manquant : en tant qu'avertissement — une contrainte inventée ou absurde est pire qu'un écart signalé.

Objectifs de recherche en sécurité

Réduisez les objectifs d'audit à un seul critère de terminaison, comme identifier, déclencher et valider une vulnérabilité de haute sévérité valide selon un fichier de modèle de menace référencé. Ce fichier, et non l'objectif, porte la portée, les capacités de l'attaquant, la base de sévérité et les résultats connus à ignorer. Utilisez un langage neutre ("déclencher et valider", pas "prouver que ceci est exploitable"), exigez des conditions préalables démontrées — l'accès supposé de l'attaquant est le faux positif le plus courant — et arrêtez pour une révision humaine après chaque résultat plutôt que d'accumuler des rapports non triés. Validez les résultats par un second passage d'un agent frais, jamais le découvreur seul.

Format

Exécutez uv run --no-project {baseDir}/scripts/format_goal_prompt.py --fenced sur le brouillon (fichier ou stdin). Il réduit les espaces à une ligne, supprime les préfixes /goal, guillemets et fences, prévient en cas d'absence de clause d'arrêt, et rejette les sorties de plus de 4 000 caractères — raccourcissez ou déplacez les détails dans un fichier et réexécutez.

Renvoie exactement un bloc text délimité, une ligne :

/goal <objectif normalisé unique>

N'ajoutez pas de prose autour — sauf lorsque des éléments de la liste de contrôle n'ont pas pu être ancrés : suivez alors le bloc par une liste Manquant :, une ligne par écart, indiquant à l'utilisateur ce qu'il doit fournir.

Exemple

Brouillon :

/goal Migrer le module d'auth :
  - remplacer legacyAuth() par auth.verify()
  - s'assurer que les tests fonctionnent toujours

Reformulé et formaté :

/goal Tous les sites d'appel legacyAuth() utilisent auth.verify() : `rg "legacyAuth\(" -t ts` n'affiche rien ET `npm test` se termine avec 0 (exécutez les deux, affichez la sortie), sans modifier vendor/ ni affaiblir aucun test. Si bloqué, arrêter et signaler les chemins tentés et le blocage, ou arrêter après 20 tours.

Ici, npm test vient du package.json du dépôt — pas d'une devinette — et l'associer à la vérification de zéro correspondance ferme l'échappatoire la plus facile : supprimer les sites d'appel au lieu de les migrer. Lorsque rien n'ancré un élément, formatez ce qui existe et signalez les lacunes :

Brouillon : rendre le checkout plus rapide, sans métrique ni benchmark dans le contexte :

/goal Rendre le checkout plus rapide

Manquant :

• état final mesurable — quelle métrique et quel seuil signifient "plus rapide"
• vérification — le benchmark ou la commande qui le prouve
• limite d'arrêt — par ex. "ou arrêter après 20 tours"