goal-instruction-writer

Goal Instruction Writer

Transformez une demande vague en une instruction Goal prête à être exécutée par un agent sans qu'il ait à deviner ce que signifient succès, progression ou arrêt. Préservez l'intention, le langage, les limites d'autorité et la portée demandée par l'utilisateur. Cette compétence conçoit et audite le contrat d'instruction ; l'accès runtime, les permissions et les approbations externes restent de la responsabilité de l'agent hôte et de l'utilisateur. Décrivez les vérifications lors de la rédaction d'un Goal ; n'exécutez la tâche sous-jacente que lorsque l'utilisateur en a aussi fait la demande.

Lisez references/goal-contract.md lors de la rédaction ou de l'audit d'un Goal. Lisez references/examples.md uniquement lorsqu'un exemple concret aiderait à clarifier la tâche demandée. Pour un travail qui s'étend sur plusieurs phases, artefacts, ou plus de quelques itérations, lisez également references/drift-control.md. Pour les workflows axés sur l'aperçu, lisez references/loop-preview.md.

Choisissez le mode

• Rédaction : construisez un Goal à partir d'une demande approximative.
• Affinage : préservez un Goal existant tout en comblant les champs manquants (objectif, preuve, boucle, terminaison).
• Audit : identifiez l'ambiguïté, la répétition illimitée, les critères invérifiables et les transitions dangereuses ou non autorisées ; proposez les corrections les plus minimes.
• Conversion : transformez une checklist, un ticket ou un brief de projet en Goal sans élargir sa portée.
• Aperçu : montrez la boucle concrète, les branches, les barrières de dérive et les conditions d'arrêt avant de rédiger le Goal final. N'émettez pas de Goal exécutable et n'effectuez pas de travail externe dans ce mode.

Si le mode n'est pas précisé, déduisez-le de l'entrée. Ne posez que des questions dont les réponses changeraient l'objectif, l'autorité, la preuve d'acceptation ou l'état terminal légal. Sinon, énoncez vos hypothèses et continuez.

Aperçu avant rédaction

Utilisez l'approche "aperçu d'abord" lorsque l'utilisateur demande "先看循环", "preview", "先设计流程" ou similaire. Privilégiez-la également pour un travail multi-étapes, coûteux, irréversible ou matériellement incertain. Pour une tâche courte et réversible, une rédaction directe suffit.

L'aperçu est un point de contrôle de conception, pas une autorisation d'exécuter :

1. Indiquez le résultat provisoire, la référence de base et les hypothèses.
2. Montrez la boucle sous forme de transitions d'état concrètes, incluant la première unité de travail, les branches de réussite et d'échec, les preuves de progression, les vérifications de dérive, les barrières de phase et les états d'arrêt légaux. Distinguez les vérifications d'itération des vérifications de phase ou de livraison plus larges, y compris la réutilisation des preuves et les limites pour les vérifications coûteuses.
3. Listez les décisions qui pourraient changer la boucle ou sa portée. Pour le feedback, l'adoption, le pilote, le lancement ou la validation, incluez le seuil de preuve, ce qui compte et la fenêtre de feedback.
4. Terminez par un passage de relais clair : attendez que l'utilisateur confirme ou révise la boucle avant de générer le Goal final.

Lorsque l'utilisateur confirme, reportez l'aperçu accepté dans le Goal final sans modifier silencieusement sa boucle, sa portée ou ses règles de terminaison. Si l'utilisateur le révise, regénérez l'aperçu ou enregistrez d'abord la décision modifiée. Une réponse d'aperçu ne doit pas prétendre que le Goal est complet et ne doit pas produire d'effets secondaires externes simplement parce qu'une boucle a été décrite.

Construisez le contrat à trois couches

1. Goal : définissez le résultat

Écrivez une phrase avec un état final observable. Elle doit indiquer quel artefact, comportement, décision ou changement vérifié existera lorsque le travail sera terminé. Ensuite, rendez le contrat concret :

• Référence de base : ce qui existe maintenant et quelle révision, source ou quels faits sont faisant autorité.
• Périmètre : ce qui peut changer et ce qui est gelé.
• Critères d'acceptation : vérifications observables liées à des preuves, et non à des activités comme "continuer à travailler" ou "essayer plus fort".
• Dépendances et autorité : outils, accès, décisions du propriétaire et barrières externes que l'agent peut ou ne peut pas franchir.
• Livrable : les fichiers, la décision, le rapport ou le message qui sera remis.

Pour les Goals concernant le feedback, l'adoption, les pilotes, les lancements ou la validation, définissez un seuil de preuve de feedback avant la rédaction : ce qui compte comme feedback, si un point d'entrée est suffisant ou si au moins N réponses non-auteurs sont requises, et la fenêtre de temps ou de tentatives. Ne comptez pas l'activité de l'auteur uniquement, sauf si l'utilisateur choisit explicitement ce seuil.

Préférez un seul résultat porteur par Goal. Divisez les résultats non liés en Goals séparés. Remplacez les verbes vagues comme "améliorer", "gérer" ou "terminer" par un résultat mesurable.

Prévenez la dérive dans les travaux de longue durée

Pour un Goal long ou multi-étapes, figez une Ancre de Goal compacte avant la première itération : la phrase de résultat, les identifiants des critères, le périmètre gelé et la phase actuelle. Traitez-la comme un invariant. Une nouvelle découverte peut changer le plan, mais ne doit pas changer silencieusement le résultat, les critères d'acceptation ou l'autorité. Une décision explicite du propriétaire crée une nouvelle version du Goal ou un enregistrement de changement de périmètre.

À chaque itération, enregistrez trois liens avant d'agir :

1. Critère cible : quel critère d'acceptation ce travail fait progresser.
2. Delta attendu : quelle preuve observable devrait changer si cela fonctionne.
3. Raison de périmètre : pourquoi cette action est à l'intérieur de la limite gelée maintenant.

Après vérification, classez le résultat comme :

• ON_TARGET : le critère nommé a progressé et les preuves soutiennent l'étape suivante.
• SIDE_QUEST : utile mais pas requis pour ce Goal ; mettez-le de côté dans une liste différée au lieu d'élargir la boucle.
• DRIFTED : aucun critère n'a progressé, l'action a changé l'objectif ou le périmètre, ou la prochaine étape ne peut pas être justifiée à partir de l'Ancre ; arrêtez et réalignez.

Exécutez une barrière de phase toutes les 3 à 5 itérations par défaut, à chaque jalon, et avant une action irréversible ou coûteuse. Relisez l'Ancre, comparez l'état actuel avec la référence de base, marquez les critères comme ouverts ou vérifiés, examinez les quêtes secondaires différées et choisissez une action justifiée. Ne réécrivez jamais les critères pour faire apparaître un travail terminé comme étant sur la cible.

2. Boucle : définissez comment la progression est faite

Utilisez une itération bornée avec un signal de progression visible :

1. Inspectez l'état actuel et le dernier curseur durable.
2. Sélectionnez la plus petite unité de travail suivante, nommez son critère cible, le delta attendu et la raison de périmètre.
3. Agissez dans le périmètre et l'autorité autorisés.
4. Vérifiez le résultat par rapport au critère pertinent en utilisant la stratégie de vérification ci-dessous ; capturez la preuve.
5. Classez le résultat comme ON_TARGET, SIDE_QUEST ou DRIFTED et appliquez la règle de dérive correspondante.
6. Enregistrez le delta, l'écart restant, la décision et le prochain curseur avant une autre itération.

Indiquez la limite d'itération qui correspond à la tâche : une timebox, un budget d'outil ou de token, un nombre maximum de tentatives, ou une liste finie d'unités de travail. Ajoutez une règle de non-opération : ne répétez pas la même action sans nouvelle information ; après un échec répété, changez l'hypothèse ou arrêtez-vous avec le bloqueur. La boucle doit pouvoir expliquer pourquoi la prochaine itération est différente de la précédente.

Stratégie de vérification

Incluez une courte stratégie de vérification dans le Goal. Préservez les exigences d'acceptation explicites de l'utilisateur et du référentiel tout en contrôlant quand les vérifications s'exécutent :

• Vérifications d'itération : choisissez les vérifications les plus petites suffisantes pour le comportement affecté. Élargissez en cas d'impact de changement, de nouveaux échecs, d'incertitude non résolue ou d'une barrière requise.
• Vérifications de phase et de livraison : une fois que l'implémentation pertinente est stable, terminez les vérifications restantes requises de régression, de build, d'intégration et d'artefact. Une barrière de phase examine les preuves actuelles ; elle ne répète pas automatiquement l'ensemble de la pipeline de validation et de livraison.
• Réutilisation des preuves : liez les résultats à la source ou à l'artefact vérifié, aux entrées pertinentes, aux dépendances et à l'environnement. Reportez les résultats tant que ces conditions restent valides. Les changements de documentation ou de reçu n'invalident pas les vérifications runtime non liées. Distinguez les preuves réutilisées des vérifications nouvellement exécutées.
• Raison de réexécution : avant de répéter une vérification, nommez le changement ou la nouvelle preuve qui invalide son résultat et sélectionnez les vérifications affectées. Un changement de source ou d'artefact invalide les preuves dépendantes, y compris les vérifications des consommateurs lorsque l'artefact consommé change.
• Coût et achèvement : donnez aux vérifications coûteuses des délais d'attente de commande ou des limites de tentatives appropriés. Un délai d'attente laisse son critère non vérifié ; signalez l'écart. Terminez lorsque tous les critères ont des preuves valides et que la livraison est complète ; une vérification supplémentaire nécessite une préoccupation concrète non résolue ou un résultat invalidé.

3. Terminaison : définissez les fins légales

Rendez les états terminaux explicites et mutuellement compréhensibles :

• Complet : tous les critères d'acceptation sont vérifiés et le livrable est disponible.
• Bloqué : une dépendance nommée, une autorité manquante ou un échec non résolu empêche la prochaine action significative ; signalez exactement ce qui est nécessaire pour débloquer.
• En pause : le propriétaire demande explicitement une pause ; préservez le curseur et ne reprenez pas sans autorisation.
• Timeboxé/Budgétisé : la limite est atteinte avant la fin ; signalez la progression vérifiée, l'écart restant et l'action la plus sûre suivante.
• Arrêté : le propriétaire annule le travail ou une action dépasserait l'autorité accordée ; ne continuez pas silencieusement.
• Réalignement requis : une vérification de dérive échoue ; arrêtez la boucle actuelle, préservez le point de contrôle et ne reprenez qu'après avoir réancré la prochaine action. Utilisez GOAL PAUSED: realignment required lorsqu'une étiquette terminale locale est nécessaire.

N'utilisez pas "continuer jusqu'à satisfaction", "essayer indéfiniment" ou une affirmation de réussite basée uniquement sur l'effort. Si la tâche a une convention locale pour les chaînes terminales, préservez-la ; sinon, donnez à chaque état une étiquette courte et exacte et exigez que la réponse finale l'inclue. Un objectif ou un critère d'acceptation ne peut pas être modifié simplement parce que le travail actuel est devenu difficile ou intéressant.

Produisez la réponse

Retournez le résultat dans la langue de l'utilisateur. Sauf s'il demande un autre format, utilisez cet ordre :

1. Notes de conception : un court paragraphe expliquant l'objectif, la boucle, la terminaison et les choix de contrôle de dérive ; listez les hypothèses ou les questions ouvertes à forte valeur.
2. Aperçu de la boucle : en mode Aperçu, montrez les transitions d'état, les branches, les preuves, les barrières de dérive, les états terminaux et les décisions non résolues ; arrêtez-vous là et attendez la confirmation.
3. Goal prêt à copier-coller : en mode Rédaction, Affinage ou Conversion, incluez l'instruction complète dans un bloc de code avec les sections Objectif, Ancre du Goal, Référence de base et périmètre, Critères d'acceptation, Preuve de feedback (le cas échéant), Stratégie de vérification, Boucle d'exécution, Contrôle de la dérive, Limites et règle de non-opération, Terminaison et Rapport.
4. Notes d'audit : si vous affinez ou auditez, nommez chaque ambiguïté restante et le plus petit changement qui la résout.

Le bloc prêt à copier-coller doit être exécutable comme une instruction, et non une discussion sur la façon d'écrire une instruction. Gardez les vérifications d'acceptation et les états terminaux suffisamment concrets pour qu'un relecteur ultérieur puisse les décider à partir des preuves.