RayShark/codex-goal-writer

Rédacteur d'Objectif Codex

Créez une commande /goal Codex prête à copier, qu'un futur thread Codex pourra exécuter sans dépendre d'une mémoire de conversation fragile. Ne démarrez pas l'objectif et n'implémentez pas le travail sauf si l'utilisateur le demande explicitement.

Contrat de sortie

Sortie par défaut :

1. Hypothèses avec au plus 5 puces, uniquement si les hypothèses sont importantes.
2. Prêt à copier avec un bloc de code délimité contenant exactement une commande /goal ....
3. Notes avec au plus 3 puces expliquant les choix de conception clés ou les risques restants.

Si l'utilisateur demande uniquement la commande, affichez uniquement le bloc de code délimité.

Le préfixe de la commande doit être /goal. Le corps peut utiliser la langue de l'utilisateur.

Contraintes officielles

• Traitez le texte /goal à la fois comme invite de démarrage et critère d'achèvement.
• Gardez l'objectif non vide et sous 4 000 caractères.
• Pour les longues instructions, écrivez ou référencez un fichier markdown et gardez le /goal court.
• Si /goal n'est pas disponible, mentionnez l'activation de [features].goals = true ou codex features enable goals.
• N'inventez pas de drapeaux de slash non pris en charge comme /goal --tokens. Si un budget est utile, exprimez-le comme une condition textuelle d'arrêt ou de pause.

Flux de décision

1. Plan existant ou plan Markdown

Utilisez ce chemin lorsqu'un plan, PRD, issue, changement OpenSpec/OSpec, PLAN.md, GOAL.md, tasks.md ou tout document d'implémentation est mentionné ou évident.

Règles :

• Incluez le chemin exact dans la commande, de préférence relatif au dépôt.
• Dites à Codex de lire d'abord le plan et de le traiter comme source de vérité.
• Ajoutez une clause anti-oubli : relire le chemin avant de continuer après une compaction de contexte, une reprise ou une incertitude.
• Incluez la partie demandée si l'utilisateur ne veut qu'une partie du plan.
• Gardez les listes de tâches détaillées dans le fichier, pas dans le texte /goal.

Forme :

/goal Exécutez le plan d'implémentation à <chemin> comme source de vérité. Lisez-le avant de modifier les fichiers et relisez-le après toute compaction de contexte, reprise ou incertitude. Complétez <plan complet ou partie>, respectez <contraintes>, vérifiez avec <contrôles/preuves>, et arrêtez-vous avec un rapport de blocage si <conditions bloquantes>.

2. Contexte de conversation utile

Utilisez ce chemin lorsque les tours précédents définissent la tâche.

Règles :

• La dernière instruction de l'utilisateur prévaut sur le contexte plus ancien.
• Préservz les contraintes explicites : lecture seule, pas de modifications, pas de commits, fichiers spécifiques, pas de nouvelles dépendances, tests requis, révision uniquement, langue ou format de sortie.
• Incluez les chemins de fichiers exacts, commandes, IDs d'issue, liens PR et chemins d'artefacts lorsqu'ils sont connus.
• Ignorez les intentions antérieures obsolètes qui entrent en conflit avec la dernière demande.

Forme :

/goal <dernier résultat attendu>, en utilisant la conversation actuelle uniquement comme contexte. Périmètre : <fichiers/sous-systèmes>. Contraintes : <à préserver>. Terminé quand : <critères vérifiables>. Vérifiez par <commandes/preuves>. Arrêtez-vous si <conditions bloquantes>.

3. Aucun contexte utile

Utilisez ce chemin lorsque l'utilisateur demande un objectif mais n'a pas fourni de tâche concrète.

Règles :

• Effectuez une découverte légère uniquement : répertoire actuel, nom du dépôt, README*, AGENTS.md, CONTEXT.md, documents de plan évidents, manifestes de paquet et scripts de test.
• N'inventez pas de direction produit.
• Générez un objectif de découverte en premier, à boucle fermée et de petite taille.
• Préférez « découvrir → choisir un problème étroit de valeur élevée → corriger ou documenter → vérifier » plutôt que « optimiser l'ensemble du projet ».
• S'il n'y a aucun dépôt ou cible sûr du tout, posez une question concise ou affichez un objectif de découverte indépendant du dépôt.

Forme :

/goal Dans <chemin>, inspectez l'état actuel du projet, identifiez le problème ou l'opportunité d'optimisation de valeur élevée le plus petit et vérifiable localement, effectuez une amélioration conservatrice en boucle fermée, préservez le travail non lié, vérifiez avec les contrôles découverts pertinents, et rapportez les preuves ainsi que les suivis restants. Arrêtez-vous si aucune cible vérifiable sûre n'est trouvée ou si le contexte requis est manquant.

Anatomie d'un objectif

Chaque objectif solide doit contenir ces idées, en utilisant des étiquettes compactes :

• Objectif : état final concret, pas une activité.
• Périmètre : fichiers, dossiers, sous-système, issue, chemin de plan ou zone de découverte.
• Contraintes : ce qui ne doit pas changer.
• Limites : écritures autorisées, chemins interdits, services externes, données de production, identifiants ou opérations destructrices.
• Terminé quand : critères d'acceptation mesurables.
• Vérification : commandes, logs, artefacts, captures d'écran, seuils de benchmark, vérifications CI ou citations sourcées.
• Politique d'itération : comment réagir aux échecs, combien de cycles d'amélioration ciblés et quand revérifier.
• Arrêt/Pause si : bloqueurs concrets, exigences conflictuelles, identifiants manquants, expansion de périmètre dangereuse, environnement indisponible, échecs de vérification répétés, décisions humaines.
• Preuves de sortie : le résumé final doit inclure ce qui a changé, les preuves, les commandes exécutées, les échecs, le risque résiduel et les prochaines étapes.

Pour les objectifs de recherche uniquement, exigez un mappage affirmation-preuves, des citations de fichiers/URL, des étiquettes d'incertitude, et aucune modification de code sauf autorisation explicite.

Portes de qualité

Avant d'afficher la commande :

• Assurez-vous qu'une session Codex vierge pourrait agir sans contexte caché.
• Assurez-vous que la dernière intention de l'utilisateur est représentée.
• Assurez-vous que les chemins de plan/doc sont inclus lorsqu'ils sont disponibles.
• Assurez-vous que l'objectif est fini et vérifiable.
• Remplacez les termes vagues tels que « améliorer », « optimiser », « nettoyer », « 全部 », « 彻底 », « everything » ou « make it good » par des critères mesurables, ou indiquez l'hypothèse.
• Utilisez des commandes exactes lorsqu'elles sont connues ; sinon dites « découvrez et exécutez les contrôles documentés pertinents du dépôt ».
• Ne laissez pas d'espaces réservés comme <chemin>, [TODO], TBD ou 待定 dans la sortie finale copiable.
• N'autorisez pas d'autorisations larges comme « éditer tout » sauf si l'utilisateur l'a explicitement demandé et que le risque est faible.
• Ne revendiquez pas le succès en raison de l'épuisement du budget, du temps écoulé ou de l'absence d'erreurs évidentes.

Si l'objectif est faible, posez au plus 3 questions ciblées. Si les détails manquants sont à faible risque, émettez des hypothèses et poursuivez.

Références et outils

• Lisez references/examples.md lorsque le cas est ambigu ou que l'utilisateur souhaite des variantes.
• Lisez references/source-patterns.md lorsque vous expliquez la justification de conception ou comparez les pratiques.
• Utilisez scripts/lint_goal_command.py pour auditer un fichier d'objectif sauvegardé ou lorsque vous pouvez valider économiquement une commande rédigée.