Définir l'objectif

Vue d'ensemble

Transformer l'intention de l'utilisateur en objectif qu'un agent peut poursuivre honnêtement. Privilégier les résultats mesurables, les preuves explicites et une portée délimitée plutôt que des descriptions d'activités.

Cette compétence couvre uniquement la définition d'objectif et la création d'outils d'objectif. Ne pas créer d'artefacts de planification intermédiaire, d'instantanés durables, de registres, de journaux de décision ou de fichiers de résumé à partir de cette compétence.

Workflow

1. Confirmer que la définition d'objectif est réellement nécessaire.

   • Utiliser cette compétence quand l'utilisateur demande $define-goal, demande de créer ou de définir un objectif, demande l'outil d'objectif, ou souhaite de l'aide pour transformer une intention en objectif clair.
   • Si l'utilisateur ne demande que du travail d'implémentation ordinaire, faire le travail directement au lieu de forcer la création d'un objectif.

2. Reformuler l'objectif probable en termes concrets. Un objectif utilisable nomme :

   • le résultat spécifique qui sera vrai
   • l'artefact principal, le système, le repo, l'environnement ou le comportement visible à l'utilisateur impliqué
   • comment la complétude sera vérifiée
   • ce qui est dans la portée
   • ce qui est hors de portée quand l'ambiguïté aurait de l'importance
   • la condition d'arrêt pour poser la question à l'utilisateur plutôt que de persévérer

3. La rendre quantitative quand le domaine le permet. Préférer les chiffres qui représentent un vrai succès, non une précision décorative :

   • validateurs pass/fail : tests exacts, vérifications, jobs CI, évals, commandes ou critères d'acceptation
   • seuils de qualité : latence, taux d'erreur, coût, précision, rappel, pertinence, couverture, taux de flakiness, taille du bundle, mémoire, disponibilité, taux de complétude ou critères d'examen manuel
   • contraintes d'artefacts : chemins de fichiers, modules affectés, commandes autorisées, formats de sortie, environnements cibles, délais ou rayon de blast maximal
   • comptes de preuves : nombre d'échecs reproduits, réexécutions réussies, exemples examinés, enregistrements migrés, commentaires traités ou cas vérifiés

4. Réparer les objectifs faibles avant de les définir.

   • Réécrire les objectifs vagues en objectifs mesurables quand le contexte local rend la réécriture sûre.
   • Poser une seule question de clarification concise quand le détail manquant change le résultat prévu ou la validation.
   • Rejeter les objectifs pures activités tels que « faire des progrès », « continuer d'investiguer », « améliorer les choses » ou « travailler sur X » à moins qu'ils ne soient affinés en résultat vérifiable.

5. Vérifier l'état actif de l'objectif avant de créer un objectif.

   • Appeler get_goal.
   • S'il n'y a pas d'objectif actif et que l'objectif atteint la barre de qualité, appeler create_goal.
   • S'il y a un objectif actif qui correspond toujours à l'intention de l'utilisateur, continuer à l'utiliser au lieu de créer un doublon.
   • S'il y a un objectif actif qui entre en conflit avec la nouvelle demande, demander s'il faut terminer l'objectif actuel, le marquer comme complété s'il est fait, ou démarrer un thread soutenu par un objectif séparé.

6. Créer l'objectif seulement après qu'il ait passé la barre de qualité.

   • Utiliser une seule chaîne d'objectif concise.
   • Inclure les preuves de vérification dans l'objectif lui-même.
   • Inclure les limites de portée quand elles contraignent le travail.
   • Inclure un budget de tokens uniquement quand l'utilisateur l'a explicitement demandé.
   • Ne pas appeler create_goal pour une tâche ordinaire multi-étapes à moins que l'utilisateur n'ait explicitement demandé du travail soutenu par un objectif.

Barre de qualité d'objectif

Avant create_goal, l'objectif doit répondre à :

• Quelle chose concrète sera vraie quand ce sera fait ?
• Quelles preuves le prouveront ?
• Quel seuil quantitatif ou binaire définit le succès ?
• Quelles limites de portée importent ?
• Qu'est-ce qui devrait faire arrêter l'agent et poser la question ?

Bon :

Réduire la latence p95 de l'API checkout sous 250 ms pour le chemin lent documenté en apportant la plus petite modification côté serveur sûre, puis vérifier avec npm run test:checkout et le benchmark de latence local existant montrant p95 sous 250 ms sur 3 exécutions consécutives.

Bon :

Résoudre les commentaires d'examen ouverts sur la PR 123 qui demandent des modifications de code, mettre à jour uniquement les fichiers d'auth affectés et les tests, et vérifier avec la commande de test auth ciblée plus gh pr view 123 montrant aucun thread de demande de modification non résolu.

Faible :

Rendre le checkout plus rapide.

Faible :

Continuer d'investiguer les commentaires de la PR.

Heuristiques de quantification

• Pour les bugs, définir le succès comme d'abord la reproduction, puis la correction, et un validateur qui échoue puis réussit quand possible.
• Pour les tests, nommer la commande exacte et la condition de réussite requise.
• Pour la performance, nommer la métrique, le seuil cible, la méthode de mesure et le nombre d'exécutions.
• Pour le travail de qualité, définir une barre d'acceptation observable telle que des exemples examinés, lint/typecheck/test réussi ou artefact approuvé par l'utilisateur.
• Pour la recherche, définir la décision que la recherche doit permettre, les sources ou systèmes dans la portée et la norme de preuve.
• Pour les opérations, définir l'état sain, la fenêtre de monitoring, le seuil d'échec et le déclencheur de rollback ou d'escalade.

Questions de clarification

Poser la question uniquement quand une réécriture raisonnable risquerait de poursuivre le mauvais résultat. Garder la question courte et orientée autour du validateur manquant ou de la limite de portée.

Formes de questions utiles :

• « Quelle métrique devrait définir le succès ici : latence, coût, précision ou comportement visible à l'utilisateur ? »
• « Quel environnement dois-je vérifier : local, staging ou production ? »
• « Quel est le minimum de preuves que tu souhaites avant que je marque cet objectif comme complété ? »

Si l'utilisateur ne peut pas fournir une métrique, proposer le validateur binaire le plus honnête disponible et demander confirmation.