Ambition
Aidez l'utilisateur à choisir un résultat plus précieux. Il s'agit d'un workflow consultatif : s'invoquer n'autorise pas l'implémentation, une expérience payante, une publication, ou une mission. N'en faites pas une étape obligatoire avant un travail déjà autorisé, ne réduisez pas une mission existante à un prototype, ni n'étendez cette mission.
Cadrer les options
Utilisez le projet, l'idée ou l'objectif nommé. Lisez les instructions pertinentes du projet, le comportement actuel, la feuille de route ou la proposition abandonnée, et les outils disponibles. Inspectez juste assez pour identifier la contrainte qui rendait l'idée peu attrayante auparavant. Si aucun projet ne peut être déduit, demandez quel projet ou résultat considérer. Si aucune contrainte historique n'est documentée, étiquetez-la comme une inférence à partir de la conception actuelle. N'inventez pas de décision antérieure ni de changement de capacité.
Séparez trois choses dans vos notes et votre résultat :
- Observé : ce que les fichiers, l'application en cours d'exécution ou l'utilisateur établissent.
- Supposé : ce qui devrait être vrai pour que l'option soit rentable.
- Capacité non testée : ce que l'agent ou l'outil n'a pas encore démontré ici.
Vérifiez les affirmations modifiables concernant les outils ou modèles externes par rapport aux sources primaires actuelles. Une démo ou un benchmark impressionnant est une raison de tester une hypothèse, pas une preuve que ce projet particulier est désormais réalisable. Nommez l'accès ou les données manquants au lieu de supposer qu'ils peuvent être acquis.
Proposer trois résultats
Donnez trois options significativement différentes, chacune avec :
- Le résultat concret et qui en bénéficierait.
- L'ancienne contrainte remise en question et la preuve qu'elle a peut-être changé.
- L'incertitude restante la plus difficile, l'effort probable et l'inconvénient matériel.
- Une référence de source pour les faits du projet ; étiquetez les estimations et les inférences.
Préférez les options qui changent ce que l'utilisateur peut accomplir. Plus de code généré, plus d'agents ou une liste de fonctionnalités plus longue n'est pas en soi un meilleur résultat. Incluez les workflows spatiaux, interactifs, de recherche ou d'application uniquement lorsqu'ils servent le projet réel. Si moins de trois options sont défendables, dites-le plutôt que de gonfler la liste.
Recommandez une option et expliquez pourquoi elle surpasse les alternatives. Il est valide de recommander de laisser la portée actuelle inchangée lorsqu'il n'y a pas d'avantage convaincant.
Concevoir l'expérience décisive
Pour l'option recommandée, spécifiez :
- Hypothèse : l'affirmation incertaine que l'expérience va résoudre.
- Plus petit artefact convaincant : quelque chose que l'utilisateur peut exécuter, inspecter ou utiliser.
- Procédure : entrées concrètes, environnement, outil ou commande, et résultat. Si un script n'existe pas, identifiez sa création comme un travail ; ne présentez pas une commande inventée comme exécutable. Énoncez la comparaison ou la référence.
- Réussite/échec : critères d'acceptation observables, y compris ce qui falsifierait l'idée. Distinguez les preuves fonctionnelles du jugement subjectif de l'utilisateur.
- Ressources : un plafond proposé de temps/dépenses/tokens et l'accès requis. Respectez tout budget fourni. Une estimation ou un plafond proposé n'est pas une autorisation de dépenser, et une utilisation inconnue doit rester inconnue.
- Décision suivante : ce qu'un résultat réussi, un échec ou un résultat non concluant justifierait.
N'exécutez pas l'expérience en silence. Lorsque l'utilisateur l'autorise, utilisez les outils d'exécution et de vérification existants. S'il demande également une continuité durable, transmettez le résultat sélectionné, les contraintes, les jalons et les critères d'acceptation à la compétence de mission, si elle est installée ; sinon, donnez un transfert autonome.
Livrable
Gardez le résultat facile à comparer : un court paragraphe de contexte, un tableau d'options, l'expérience recommandée et la décision attendue de l'utilisateur. Préservez le résultat prévu complet tout en rendant ses hypothèses incertaines testables. Une décision d'expérience facultative ne met pas en pause d'autre travail autorisé.