ARQAWA/cursor-pi

Définir l'Objectif

Présentation

Façonner l'intention de l'utilisateur en un résultat concret avec un périmètre délimité et des motifs de complétion tirés de la demande. La vérification ordinaire utilise la lecture et l'évaluation logique sous la règle de l'invite principale ; n'utilisez des chiffres que lorsqu'ils expriment une exigence réelle.

Cette compétence couvre uniquement la définition d'objectif et la création d'outil d'objectif. Ne créez pas d'artefacts de planification intermédiaires, d'instantanés durables, de registres, de journaux de décisions ou de fichiers de reprise à partir de cette compétence.

Seul le Main racine gère l'Objectif natif. Sa sélection n'ajoute aucun test, revue, délégation, permission ou autre flux de travail. Le Gold Standard évalue indépendamment l'état de travail utile, avec ou sans Objectif. Le Notebook peut rejoindre automatiquement un Objectif sélectionné selon ses propres conditions, sans autre demande manuelle ; l'Objectif seul ne l'exige pas. Conservez les notes opérationnelles utiles sous cette politique, en dehors de cette procédure de définition ; l'objectif et l'état natifs restent faisant autorité.

La définition seule n'autorise pas l'exécution de la tâche proposée. L'Objectif ne remplace jamais l'approbation ou la confirmation d'exécution requise : la préparation ToSpec ne démarre pas l'Objectif d'exécution futur, tandis qu'un Objectif de préparation explicitement sélectionné ne concerne que le résultat de préparation demandé. La sélection automatique ne remplace pas une pause utilisateur ni ne transforme un blocage, une attente d'approbation, une fin de tour ou une annulation sans abandon en complétion. Suivez les règles d'état natives réelles ; la complétion nécessite le résultat réel et toutes les actions déjà obligatoires.

Flux de travail

1. Évaluez si l'Objectif est utile pour l'ordre actuel réel.

   • Sélectionnez-le automatiquement lorsqu'un résultat demandé indépendamment a besoin de continuité à travers des étapes dépendantes, des recherches substantielles ou de l'incertitude, ou une exécution prolongée, sous réserve de la vérification d'autorité à l'étape 6.
   • Les questions courtes, les modifications brèves simples et la discussion de travaux futurs possibles ne nécessitent pas d'Objectif. Une découverte demandée peut elle-même avoir un résultat concret ; en discuter n'autorise pas son exécution.
   • Un /goal direct, une demande de création d'objectif ou une demande de définition d'objectif sélectionne cette compétence, quelle que soit la complexité. Une instruction de travailler sans Objectif prévaut sur la sélection automatique pour la tâche concernée.
   • Réévaluez après un changement matériel dans la tâche, pas à chaque appel d'outil ; n'utilisez pas de seuils pour les commandes, les minutes ou les fichiers.

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

   • le résultat spécifique qui sera vrai
   • le principal artefact, système, dépôt, environnement ou comportement visible par l'utilisateur impliqué
   • comment le résultat réel sera établi par la lecture et l'évaluation logique, plus toute preuve explicitement requise
   • ce qui est dans le périmètre
   • ce qui est hors périmètre lorsque l'ambiguïté importerait
   • la condition d'arrêt pour demander à l'utilisateur au lieu de persévérer

3. Utilisez des critères qui représentent le résultat demandé.

   • Dérivez le résultat, les chemins d'artefacts, le périmètre, le format, les valeurs et les conditions de complétion binaires de la demande.
   • N'inventez pas de métriques, seuils, validateurs ou nombres d'exécutions pour une mesurabilité formelle.
   • Les tests, commandes, CI, mesures et décomptes de preuves sont des options uniquement pour les preuves empiriques explicitement demandées ou une procédure spécifiquement adoptée ou une obligation de priorité supérieure.
   • Pour les corrections ordinaires, l'analyse ou le travail de performance basé sur l'architecture, définissez la complétion par le résultat réel et l'évaluation logique.

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

   • Réécrivez les objectifs vagues en critères de résultat concrets lorsque la demande et le contexte local rendent cette interprétation sûre.
   • Posez une question de clarification concise lorsque le détail manquant change le résultat attendu ou la validation.
   • Rejetez les objectifs d'activité pure comme « faire des progrès », « continuer à enquêter », « améliorer les choses » ou « travailler sur X » à moins qu'ils ne soient affinés en un résultat vérifiable.

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

   • Lisez l'instantané actuel de l'Objectif natif racine depuis scope_focus_native_context. Validez conversationId, goalId, objective et l'état natif (0 non spécifié, 1 actif, 2 en pause, 3 terminé, 4 effacé). Une absence d'état racine valide signifie aucun objectif ; une identité/état inconnu est inconnu, pas une absence. Les enfants ne gèrent pas l'Objectif racine. Utilisez uniquement les champs de budget natifs réels lorsqu'ils sont fournis ; ne les inventez pas.
   • Utilisez les outils natifs disponibles create_goal/update_goal et leurs schémas actuels. Cursor create_goal prend un objective ; ne passez pas de champ de budget propre à Codex. Une capacité native requise manquante arrête sa transition dépendante ; ne simulez pas l'Objectif ni ne prétendez à une préparation complète.
   • S'il n'y a pas d'objectif non terminé, que l'objective atteint le niveau de qualité et que l'étape 6 autorise la création, appelez create_goal.
   • Réutilisez un objectif non terminé correspondant selon les instructions actuelles de l'utilisateur et l'état natif ; une sélection répétée ne crée pas de doublon ni ne répète des opérations terminées.
   • Préservez un objectif non terminé en conflit. Ne le réinitialisez pas, ne le remplacez pas et ne le marquez pas comme terminé uniquement pour faire de la place. Résolvez uniquement le conflit matériel via un chemin natif autorisé ou une question ciblée à l'utilisateur ; n'exigez pas un nouveau fil.

6. Créez l'objectif uniquement après qu'il a passé la barre de qualité.

   • Choisir cette compétence n'autorise pas en soi create_goal. Suivez les instructions réelles de l'outil et les règles de priorité supérieure. L'expression de l'adoption par l'utilisateur de l'Objectif automatique conditionnel, ou une instruction système/développeur applicable, fournit une demande permanente uniquement là où ces règles l'acceptent. La disponibilité de la compétence ou une tâche ordinaire seule n'est pas cette autorité ; si l'hôte nécessite une demande explicite séparée, n'inférez pas la permission contre cette exigence.
   • Si l'Objectif natif est indisponible ou non autorisé, ne le simulez pas avec des fichiers ou un autre contrôleur. Continuez le travail autorisé compatible ; divulguez la limitation concrète uniquement lorsqu'elle est matérielle pour le résultat ou un Objectif explicitement demandé.
   • Utilisez une chaîne d'objective concise unique.
   • Incluez des motifs suffisants de complétion : le résultat demandé évalué par la lecture et la logique, plus toute preuve explicitement obligatoire. Chaque seuil ou méthode ajouté doit suivre la demande ; son écriture dans l'objective ne crée aucune autorité.
   • Incluez les limites de périmètre lorsqu'elles contraignent le travail.
   • Un budget est fourni uniquement lorsqu'il est explicitement demandé et supporté par le schéma natif réel. Si un budget demandé ne peut pas être représenté par l'Objectif natif Cursor, arrêtez cette transition dépendante et divulguez la capacité manquante ; ne supprimez pas silencieusement ou ne simulez pas le budget.
   • Formulez un objectif autorisé clair sans redemander simplement pour activer le mode ou approuver son libellé technique. Demandez uniquement lorsqu'un choix manquant change matériellement le résultat demandé, l'autorité ou la preuve obligatoire. Une demande de définition uniquement reste définition uniquement.

Barre de Qualité de l'Objectif

Avant create_goal, l'objective devrait répondre :

• Quelle chose concrète sera vraie lorsque ce sera terminé ?
• Quels matériaux et motifs logiques réels l'établissent, et quelles preuves empiriques l'utilisateur a-t-il explicitement requises ?
• Quel résultat demandé ou condition quantitative ou binaire significative définit le succès ?
• Quelles limites de périmètre importent ?
• Qu'est-ce qui devrait amener l'agent à s'arrêter et demander ?

Bon :

Remplacer A par B dans le paramètre spécifié. Terminer lorsque la modification est présente et que la lecture du code affecté établit la cohérence avec la demande.

Bon :

Résoudre la question de conception spécifiée à partir de sources et de logique pertinentes. Terminer lorsque la conclusion est étayée et que les contradictions matérielles sont traitées.

Faible :

Accélérer le paiement.

Faible :

Continuer à enquêter sur les commentaires PR.

Heuristiques de Quantification

• Pour les bogues, définissez la correction requise et expliquez-la à travers le code et la logique affectés. La reproduction et un validateur échouant puis réussissant nécessitent une demande explicite pour cette preuve.
• Pour les tests explicitement demandés, nommez le scénario ordonné et sa condition de réussite ; honorez une commande spécifiée.
• Pour la performance, raisonnez à partir des mécanismes, du travail et du contexte. Étiquetez la complexité calculée comme calcul ; revendiquez une amélioration mesurée uniquement à partir de mesures réelles. N'inventez pas de métrique, cible, méthode ou nombre d'exécutions.
• Pour le travail de qualité, utilisez le résultat demandé, ordinairement évalué par la lecture et la logique ; n'ajoutez pas automatiquement de lint, de vérifications de type ou de tests.
• Pour la recherche, définissez la décision que la recherche doit permettre, les sources ou systèmes dans le périmètre et le standard de preuve.
• Pour les opérations, définissez l'état résultant demandé. N'inventez pas de fenêtres de surveillance, de seuils ou de travaux de restauration.

Questions de Clarification

Demandez uniquement lorsqu'une réécriture raisonnable risquerait de poursuivre le mauvais résultat. Gardez la question courte et orientée autour du validateur manquant ou de la limite de périmètre.

Formes de questions utiles :

• « Quelle métrique devrait définir le succès ici : la latence, le coût, la précision ou le comportement visible par l'utilisateur ? »
• « Quel environnement devrais-je vérifier : local, staging ou production ? »
• « Quelle est la preuve minimale que vous souhaitez avant que je marque cet objectif comme terminé ? »

Lorsqu'un critère significatif découle directement de la demande, formulez-le sans autre confirmation. Demandez uniquement lorsqu'un choix non résolu change matériellement le résultat ou la preuve obligatoire.