Pourquoi réviser vos instructions pour Astra ?
Rédigez-vous ces instructions pour un modèle précédent ?
« Lisez ce document à chaque fois », « Testez toujours », « Confirmez avant de commencer ». Beaucoup de personnes ont probablement ajouté ces instructions pour éviter que Codex échoue.
Parce qu'il corrigeait des choses sans lire la documentation, vous avez écrit qu'il devait d'abord la lire. Parce qu'il avançait sans autorisation, vous avez écrit qu'il devait confirmer avant de continuer.
Bien que ces phrases aient eu une raison d'être à l'époque, elles peuvent ne plus être aussi utiles lorsque le modèle change.
Les procédures décidées pour aider les modèles précédents pourraient être trop détaillées pour GPT-6 Astra. Inversement, comme vous n'avez pas communiqué le périmètre prévu, il pourrait s'arrêter pour demander une confirmation inutilement.
Ce qui doit être révisé n'est pas seulement la quantité d'instructions. Il s'agit de réduire les tâches répétitives et de clarifier les scénarios nécessaires et les conditions d'achèvement.
Eric Provencher, qui gère l'expérience développeur Codex chez OpenAI, aborde ce problème dans un article intitulé « Repenser les compétences et les prompts pour GPT-6 Astra ».
Cela couvre non seulement les requêtes que vous écrivez dans le chat, mais aussi « AGENTS.md », qui transmet les règles de travail pour les fichiers de projet dans un dépôt.
Les « Compétences » sont des ensembles de procédures et de connaissances utilisées pour des tâches spécifiques. Les instructions enregistrées ici influencent également la façon dont Codex procède.
Dans cet article, basé sur les explications d'Eric et les images de référence, nous verrons quoi réduire, quoi conserver et comment réécrire. Les exemples créés pour les lecteurs sont marqués comme « Exemples d'application » pour les distinguer des exemples originaux.
Il ne s'agit pas de blâmer tous les échecs d'Astra sur les anciennes instructions. C'est un article pour auditer les règles que vous avez accumulées afin de voir lesquelles ne correspondent plus au travail actuel.
1. Pourquoi vous devez réviser les instructions pour Astra
Le point de départ d'Eric est le changement où les instructions destinées à « surveiller » le modèle deviennent moins nécessaires qu'avant.
Auparavant, certaines tâches n'avançaient que si vous spécifiiez chaque étape dans l'ordre. Pour compenser l'ambiguïté, nous avons accumulé des procédures et des notes détaillées.
Cependant, le texte original indique que les modèles deviennent meilleurs pour gérer les différences subtiles de sens et l'ambiguïté. Il souligne que les spécifications détaillées qui étaient autrefois utiles peuvent maintenant entraver les résultats.
Ce qu'il ne faut pas mal interpréter ici, c'est qu'il ne s'agit pas d'une conversation sur le fait « d'arrêter les explications parce que le modèle est plus intelligent ».
Eric recommande également de conserver les conseils pour les documents nécessaires. Le texte original demande toujours des explications concernant le périmètre sûr de progression et le travail requis pour l'achèvement.
Même pour la même instruction, la façon dont vous la révisez change selon ce que cette phrase est censée transmettre.
Par exemple, vous devez distinguer les explications qui transmettent les circonstances spécifiques au projet de celles destinées à faire suivre les procédures aux modèles précédents.
« Les contraintes de conception sont écrites dans ce document » est un indice pour trouver des informations. D'un autre côté, « Lisez ce document entier du début pour chaque modification » fixe uniformément le moment de la lecture.
Informer le modèle de l'existence d'un document n'est pas la même chose que lui faire tout lire à chaque fois.
De plus, « L'accès à la production est interdit » et « Confirmez même avant d'exécuter des tests localement » arrêtent des actions différentes.
Ce n'est pas parce que vous voulez maintenir la première règle que la seconde est toujours nécessaire. Cependant, s'il n'est pas clair si quelque chose reste vraiment local, vous ne devez pas non plus sauter cette confirmation.
Les Compétences, AGENTS.md et les requêtes quotidiennes mentionnés dans le texte original sont tous liés à ces jugements. Même si vous corrigez une phrase dans le chat, si la même restriction reste ailleurs, l'audit n'est pas terminé.
Par exemple, que se passe-t-il si vous écrivez « Terminez-le jusqu'à ce que ça marche » dans une requête, mais que la procédure appliquée dit toujours « Arrêtez-vous toujours à la première implémentation et demandez une révision » ?
C'est un exemple pour expliquer des instructions contradictoires. Au minimum, sans organiser ce que l'utilisateur veut, le point final de la requête n'est pas aligné.
Lors de la révision, ne jugez pas sur la base de « c'est long, donc coupez-le ». Regardez si cette phrase transmet des connaissances nécessaires, détermine le périmètre de travail, ou fait simplement répéter au modèle les procédures précédentes.
Même si le texte est court, si la cible de « confirmez tout » est vague, ce n'est pas nécessairement une bonne instruction. Parfois, même si c'est un peu plus long, il est préférable de transmettre l'intention en clarifiant les conditions de lecture ou où s'arrêter.
2. Instructions à réduire : chargement répétitif et étapes trop détaillées
La première chose à auditer est les règles de chargement qui se déclenchent indépendamment du contenu du travail.
Eric explique que faire lire au modèle des quantités massives de documentation ou l'intégralité du guide du dépôt pour une simple correction de faute de frappe est excessif.
La lecture de documents met ce contenu dans les informations de travail du modèle. Le texte original souligne le problème de consommer le contexte disponible et de ralentir le travail en chargeant des explications non pertinentes.
Le contexte ici fait référence à l'ensemble des informations auxquelles le modèle se réfère pour cette tâche. S'il continue d'augmenter, il s'approche du point où l'historique de la conversation et du travail doit être compressé.
Par conséquent, plutôt que de simplement réduire le nombre de références, distinguez ce qui doit être lu pour la requête actuelle.
Exemple A : Traduction japonaise de l'image de référence
Avant révision
Lisez toujours architecture.md, database.md et deployment.md dans leur intégralité avant de modifier.
Après révision
Référez-vous à architecture.md lors du traitement des limites entre les services, à database.md lors de la modification des structures de base de données, et à deployment.md lors de la préparation au déploiement.
Ce qui a été conservé, ce sont les guides vers les trois documents. Ce qui a été changé, ce sont les conditions pour les ouvrir.
Dans cet exemple, architecture.md concerne les rôles et les connexions entre les services. database.md concerne la structure de la base de données. deployment.md concerne la réflexion de ce qui a été créé dans l'environnement d'exécution.
Dans la version « Avant », la règle « tout lire » s'applique même à une requête pour corriger une seule faute de frappe. Dans la version « Après », si la tâche consiste à modifier la structure de la base de données, elle procède au database.md correspondant.
Cela ne signifie pas que la lecture d'autres documents est interdite. Si une tâche couvre plusieurs domaines, les documents nécessaires ne se limitent pas à un seul.
Créer une autre règle uniforme comme « choisissez un seul document » à partir de cet exemple s'écarterait de l'intention originale.
Nous n'avons pas supprimé les documents nécessaires ni réduit le contenu. Nous avons réécrit la condition qui exigeait de vérifier tous les documents pour même les petits changements pour correspondre au contenu du travail.
Eric mentionne également la nécessité de maintenir les documents à jour. Même si vous organisez les conditions de référence, une vérification distincte est nécessaire pour s'assurer qu'aucune ancienne explication ne reste à la destination.
Exemple B : Exemple d'application basé sur le texte original
Vient ensuite un exemple appliqué à un scénario où Codex est chargé d'articles, de vidéos ou de publications sur les réseaux sociaux. Il ne s'agit pas d'une procédure de production publiée par Eric lui-même.
Avant révision
Pour la création de contenu, lisez toutes les procédures pour les articles, les vidéos et les publications sur les réseaux sociaux.
Après révision
Référez-vous à writing.md pour la rédaction d'articles, à video.md pour la production vidéo et à social.md pour la création de publications sur les réseaux sociaux. Pour les requêtes multi-formats, référez-vous aux procédures pertinentes.
Encore une fois, les procédures spécifiques pour les articles, les vidéos et les réseaux sociaux sont conservées. Ce qui a changé, c'est la partie qui faisait lire au modèle toutes les procédures sous le vaste parapluie de la « création de contenu ».
Si vous demandez un seul article, il procède aux instructions pour les articles. Si vous demandez un article et son message d'annonce ensemble, il procède à la fois aux procédures pour les articles et les réseaux sociaux.
S'il n'y a pas de demande de vidéo, il n'est plus nécessaire de charger l'intégralité du processus de production vidéo au point d'entrée commun.
Le texte original appelle cette approche de fournir des explications nécessaires par étapes la « divulgation progressive ». C'est une méthode qui consiste à placer des explications au point d'entrée pour juger de la destination, tout en séparant les connaissances détaillées et les procédures dans des documents ultérieurs.
Par exemple, si vous alignez les procédures complètes pour les articles, les vidéos et les réseaux sociaux à l'entrée, chaque requête entraîne la lecture d'une explication massive.
Au lieu de cela, limitez le rôle du point d'entrée à un guide : « S'il s'agit d'un article, allez à ce document ; s'il s'agit d'une vidéo, allez à celui-ci. » Vous conservez les explications détaillées sans les jeter, ce qui permet de les lire quand c'est nécessaire.
Eric explique que pour les Compétences avec plusieurs procédures de travail, le document initial doit être un guide minimal. Il doit fournir juste assez d'informations pour passer aux documents connexes ou aux scripts qui exécutent la tâche.
Créez un état où le simple fait de regarder le point d'entrée vous indique vers quel document procéder. Résumer simplement de longues explications en des courtes ne terminera pas cette organisation des références.
Si vous supprimez les précautions nécessaires dans le résumé, cela devient un problème différent. Ce qui est conservé dans l'exemple d'application ci-dessus, ce sont les procédures uniques à chaque format.
Les tests sont-ils également définis sur « Toujours, quoi qu'il arrive » ?
Le texte original indique que les modèles précédents devaient être incités à tester et à confirmer le travail. D'un autre côté, Astra le fait tout seul, donc les mêmes instructions peuvent conduire à des tests redondants inutiles.
Ne pas mal interpréter cela comme « Astra n'a pas besoin de tests ». Le problème n'est pas d'arrêter les vérifications, mais de savoir si les instructions provoquent des vérifications redondantes.
Si vous appliquez cela à vos propres paramètres, regardez quelle vérification vous demandez pour quel changement. Le contenu des inspections nécessaires et les conditions pour les répéter uniformément chaque fois que vous faites quelque chose peuvent être audités séparément.
Comme cet article ne compare pas le nombre de tests ou le temps de traitement, il ne montre pas d'effet comme « la réécriture fera gagner X minutes ». La cible de l'audit est de savoir si vous pouvez distinguer les inspections nécessaires des répétitions redondantes.
3. Réduire les instructions : quand cette compétence doit-elle être utilisée ?
Ajouter plus de Compétences ne les rend pas nécessairement plus faciles à choisir. Eric attire l'attention sur la pratique de télécharger et d'ajouter des quantités massives de Compétences.
Selon le texte original, le nom et la description de chaque Compétence sont chargés dans le contexte pour que le modèle juge quand les utiliser.
Ici, distinguez le chargement du nom/description du chargement du corps de la Compétence. Cela ne signifie pas que le modèle lit chaque corps de Compétence depuis le début.
Le modèle utilise d'abord le nom et la description comme indices pour juger lequel utiliser cette fois-ci. Si ces descriptions sont trop longues ou s'il y a trop de Compétences, le texte original indique que Codex raccourcira les descriptions pour les adapter.
En conséquence, le modèle peut ne voir qu'une partie de la description de chaque Compétence, ce qui rend le choix plus difficile. Même si les procédures nécessaires sont enregistrées, l'explication du point d'entrée peut ne pas être entièrement transmise.
De plus, Eric mentionne les contradictions entre les descriptions ou les descriptions qui essaient de se faire utiliser pour tout. Celles-ci peuvent provoquer le chargement d'instructions qui ne sont pas utiles pour la tâche.
Donc, il ne s'agit pas de bourrer les descriptions de termes techniques pour donner l'impression que la couverture est large. Faites en sorte que la description permette au modèle de savoir si elle doit être appelée pour le travail en cours.
Traduction japonaise de l'image de référence
Avant révision
Créez et vérifiez les migrations de schéma PostgreSQL. Utilisez pour le travail impliquant des bases de données, des requêtes, des modèles et de la persistance.
Après révision
Créez et vérifiez les migrations de schéma PostgreSQL. Utilisez pour l'ajout/la modification de migrations ou la révision des procédures d'application.
PostgreSQL est un type de base de données. « Migration de schéma » fait référence à la tâche de modification de la structure des tables et des éléments qui servent de conteneurs de données et d'application de ces modifications.
Par exemple, c'est un scénario où vous modifiez la structure de la base de données pour augmenter les éléments à enregistrer. Ici, il est cité comme exemple d'explication de la signification des termes.
D'un autre côté, les « requêtes » dans la description « Avant » sont des demandes de récupération ou de manipulation de données. La « persistance » fait référence à l'enregistrement des données afin qu'elles puissent être utilisées plus tard.
Ce sont des termes liés aux bases de données, mais tout travail impliquant des bases de données ne constitue pas une tâche de migration qui modifie la structure.
La première phrase de la version « Avant » montre une tâche spécialisée : « Créer et vérifier les migrations. » Cependant, la deuxième phrase inclut un large éventail de travaux liés aux bases de données dans les conditions d'utilisation.
C'est ce décalage de périmètre qui est corrigé dans l'image de référence. Le domaine d'expertise de la Compétence et les conditions d'appel ne correspondent pas.
Après la révision, le rôle de « Créer et vérifier les migrations de schéma PostgreSQL » reste. En plus de cela, il est réduit aux cas d'ajout de migrations, de modification de migrations ou de révision des procédures d'application.
Par exemple, si vous voulez simplement vérifier une requête pour récupérer des données existantes, vous n'avez pas nécessairement besoin d'appeler cette Compétence de migration simplement parce qu'elle est « liée à la base de données ».
Inversement, s'il s'agit d'une révision de la façon d'appliquer les changements structurels, c'est toujours une cible dans la description « Après ». La réduction n'a pas perdu le travail spécialisé.
Le point de confirmation lors de la correction des descriptions n'est pas seulement « de quoi cette Compétence est-elle compétente ? » C'est de savoir si l'on peut lire « pour quelle requête sera-t-elle utilisée, et à quelles requêtes ne sera-t-elle pas étendue ? »
Si vous écrivez simplement « Compétence BD » pour la rendre plus courte, les conditions d'appel disparaissent. Ce que le texte original demande, c'est de rendre la description aussi courte que possible tout en gardant les scénarios d'utilisation clairs.
Vous pouvez utiliser le « Avant/Après » ci-dessus pour vérifier si le travail demandé et les conditions d'application correspondent, plutôt que de vous fier à la force du nom ou à la longueur de la description.
4. Clarifier les instructions : jusqu'où aller et ce qui définit l'achèvement
À partir de là, nous parlons d'ajouter les explications nécessaires. Le simple fait de réduire le chargement et les procédures ne résoudra pas le problème de l'arrêt en cours de route.
Eric déclare que bien qu'Astra travaille avec diligence, il peut parfois être prudent quant à la distance à parcourir. La façon de communiquer la plage dans laquelle vous voulez qu'il continue est également une cible pour la révision mentionnée dans le texte original.
En particulier, si vous avez fortement écrit « Confirmez toujours d'abord » parce qu'un modèle précédent s'est déplacé sans autorisation, auditez cette limite.
Ce que le texte original souligne, c'est la possibilité de s'arrêter à un endroit où il était en fait acceptable de continuer, juste pour suivre strictement la limite. Il ne s'agit pas de dire d'ignorer les instructions de confirmation, mais de réécrire ce que vous autorisiez.
A : Clarifier le périmètre d'approbation
Le texte original a un exemple de test local qui utilise des données de test jetables et n'accède pas à la production. C'est un exemple d'autorisation de cette tâche spécifique dans votre propre environnement de travail.
Le « Avant » suivant est un exemple d'application créé pour le contraste. Le « Après » contient une traduction japonaise des instructions de test local du texte original.
Avant révision : Exemple d'application pour le contraste
Demandez une approbation à chaque fois avant d'exécuter un test et avant de corriger un échec.
Après révision : Traduction de l'exemple original
Les tests locaux utilisent des données de test jetables et n'accèdent pas à la production. Veuillez procéder sans demander d'approbation à chaque étape jusqu'à l'exécution des tests, la correction des échecs causés par les modifications demandées et la ré-exécution des tests affectés.
Ce qui a été conservé, ce sont l'environnement cible et le périmètre de travail. Ce qui a été changé, c'est la condition de demander une approbation à chaque fois dans ce périmètre.
« Données de test jetables » et « pas d'accès à la production » ne sont pas des préfaces décoratives. Ce sont des prémisses pour juger si cette instruction peut être utilisée.
S'il s'agit en fait d'un test qui se connecte à la production, écrire « pas d'accès à la production » ne change pas l'environnement. Parfois, c'est appelé « local » mais il n'est pas clair si cela répond à ces conditions. Laissez les conditions non vérifiables telles quelles.
De plus, la correction autorisée concerne les « échecs causés par les modifications demandées ». Ce n'est pas une instruction étendue pour permettre la correction de tous les problèmes trouvés dans le test.
La cible de la ré-exécution est également écrite comme « tests affectés ». C'est différent d'une spécification uniforme pour répéter tous les tests à chaque fois.
Cette phrase spécifie les actions qui peuvent se poursuivre, mais elle n'élimine pas l'approbation pour d'autres tâches. Elle montre combien déléguer un ensemble de tâches qui ont été confirmées comme sûres.
Vous n'avez pas besoin d'aller jusqu'à « tout permettre parce que s'arrêter à chaque fois est une corvée ». Si vous séparez les tâches pour lesquelles vous ne voulez pas qu'il s'arrête des tâches pour lesquelles vous voulez toujours un jugement, le sens de la requête change.
B : Clarifier les conditions d'achèvement
Eric explique que si vous êtes habitué à GPT-5.6 Sol, qui travaille pendant longtemps, la façon dont Astra s'arrête peut sembler prudente.
Au stade où l'implémentation initiale est terminée, même s'il reste du travail, il pourrait revenir pour demander une révision. Par conséquent, il recommande de décider des conditions d'achèvement avant de commencer.
Ce qui est nécessaire est-il seulement l'implémentation, ou jusqu'à son exécution pour confirmer ? Et de plus, est-ce jusqu'à la correction des bogues trouvés lors de la confirmation ?
La personne qui émet la requête organise d'abord ces différences. Une ligne d'arrivée difficile à transmettre avec seulement « terminez-le » est écrite comme une tâche.
Ce qui suit est un exemple d'application où l'explication originale est remplacée par la création d'un formulaire de demande. Ce n'est pas le texte de requête réel d'Eric ni un résultat de vérification de comportement réel.
Avant révision
Créez un formulaire de demande. Laissez-moi vérifier une fois qu'il est implémenté.
Après révision
Créez un formulaire de demande. Cette fois, confirmez localement qu'il peut détecter les champs obligatoires vides et les adresses e-mail invalides, et que l'écran de fin apparaît après une soumission de test. Corrigez les bogues causés par cette modification et signalez-les avec les résultats de la confirmation. Ne publiez pas en production et n'envoyez pas d'e-mails réels.
Ce qui a été conservé, c'est le but de créer le formulaire de demande et de signaler les résultats à un humain. Ce qui a été changé, c'est la quantité à vérifier avant le signalement.
Dans la version « Avant », la requête est « Laissez-moi vérifier une fois qu'il est implémenté. » Même s'il s'arrête au point de l'implémentation initiale, il ne s'est pas écarté des instructions.
Si vous voulez voir le design à mi-parcours, cette façon de s'arrêter a un sens. S'il s'agit d'un arrêt pour confirmer des parties que vous n'avez pas encore décidées, c'est une instruction avec une raison de rester.
D'un autre côté, si ce que vous voulez cette fois-ci est un formulaire qui a terminé les vérifications de fonctionnement, incluez ces vérifications dans la requête. L'exemple énumère les champs vides, les e-mails invalides et l'affichage après la soumission de test.
Par rapport à simplement « vérifiez si cela fonctionne correctement », les états à essayer sont spécifiques. Si des bogues causés par cette modification sont trouvés lors de la confirmation, la cible est définie sur le signalement après correction.
En même temps, la publication en production et l'envoi d'e-mails réels sont exclus. C'est pour éviter de confondre la vérification des soumissions de test à l'écran avec la livraison d'e-mails à des destinations réelles.
Cette requête ne traite pas la fonction d'envoi d'e-mails réels comme vérifiée. Faites-lui signaler combien a été confirmé localement comme résultat.
Selon le texte original, si vous voulez aller au-delà de la première implémentation, transmettez quoi enquêter et où s'arrêter.
Plutôt que de simplement renforcer avec « ne vous arrêtez pas à mi-chemin », énumérez les confirmations nécessaires et les opérations à ne pas poursuivre. De cette façon, vous pouvez réviser même les endroits où il revient à un humain.
5. Auditer vos propres paramètres
À la fin du texte original, Eric suggère de demander à Astra un audit basé sur cet article. Un audit signifie lire les instructions existantes et vérifier les chevauchements, les divergences et les domaines qui peuvent être révisés.
Vous pouvez également ouvrir votre propre AGENTS.md ou Compétences et regarder les phrases qui vous intriguent. Cependant, si vous voulez organiser où et quelles instructions vous avez écrites, vous pouvez confier un audit avant d'apporter des modifications.
L'approche consistant à effectuer d'abord uniquement l'audit sans modifier les fichiers est une proposition de cet article. Ce n'est pas une procédure obligatoire spécifiée par Eric.
Dans ce cas, ne demandez pas à « supprimer toutes les instructions inutiles » dès le début. Ce que vous voulez d'abord, c'est du matériel qui vous permet de comparer les instructions originales avec la proposition sur la façon de les modifier.
Une autre note du texte original : les Compétences et les instructions placées dans un dépôt peuvent être utilisées par les IA d'autres travailleurs.
Ces IA pourraient ne pas utiliser le même Astra. Eric souligne que les explications utiles pour Sol ou Luna pourraient ajouter trop de contraintes pour Astra.
Même si cela vous semble trop détaillé lorsque vous utilisez Astra, cela pourrait être nécessaire pour d'autres modèles. Si vous modifiez des règles partagées, qui utilise quel modèle est également un facteur de jugement.
Si l'état d'utilisation est inconnu, ne supprimez pas en supposant que « seul Astra est utilisé ». Il suffit de confirmer les candidats à la correction tout en laissant les points peu clairs tels quels.
Le prompt d'audit suivant a été créé pour les lecteurs sur la base de cet article. Ce n'est pas un prompt publié par Eric dans le texte original.
Utilisez-le dans le projet cible et partagez le texte de l'article et le texte de la requête que vous souhaitez auditer. Si la plage lisible est limitée, acceptez-le comme un résultat d'inspection dans cette plage.
Veuillez auditer les instructions actuelles en vous basant sur les commentaires partagés de l'article d'Eric Provencher. Effectuez uniquement l'audit cette fois-ci ; ne créez, modifiez ou supprimez pas de fichiers, et ne modifiez pas les paramètres.
Les cibles sont le fichier AGENTS.md appliqué à ce projet, les noms et descriptions des Skills disponibles ainsi que les corps nécessaires à l'audit, et le texte de demande quotidienne que j'ai partagé. Veuillez lister les cibles que vous avez pu lire.
Vérifiez les problèmes suivants : ・Instructions dupliquées à plusieurs endroits ・Instructions impossibles à suivre simultanément ou ayant des objectifs conflictuels ・Règles uniformes excessives nécessitant un chargement ou une confirmation à chaque fois, quel que soit le contenu du travail ・Conditions d'application plus larges que le rôle réel du Skill ・Instructions dont la portée ou la définition de l'achèvement est floue
Pour les emplacements trouvés, catégorisez-les en candidats pour « Supprimer », « Raccourcir », « Modifier les conditions d'application » ou « Maintenir », et fournissez les raisons. Ne faites pas de la réduction du nombre de caractères un objectif en soi ; listez également les instructions qui doivent être conservées.
Pour chaque candidat, fournissez les éléments suivants : 1. Nom/emplacement du fichier ou la partie pertinente du texte de demande partagé 2. Instruction actuelle 3. Problème supposé et base du jugement 4. Révision proposée. En cas de maintien, la raison de ce choix 5. Ce qui doit être conservé et ce qui doit être modifié 6. Conditions que les humains doivent vérifier avant de modifier
Ne supprimez pas en masse les contraintes spécifiques au projet, les connaissances spécialisées, les tests nécessaires ou les approbations nécessaires. Proposez uniquement d'autoriser les tests locaux ou les corrections à se poursuivre dans la limite où les conditions environnementales, telles que les données cibles et l'absence d'accès à la production, peuvent être confirmées.
Vérifiez si d'autres modèles comme Sol ou Luna utilisent également les mêmes instructions. Si inconnu, écrivez « Inconnu » et ne présumez pas qu'il s'agit d'une règle propre à Astra.
Indiquez clairement les fichiers qui n'ont pas pu être lus, les conditions environnementales qui n'ont pas pu être confirmées et les informations manquantes pour le jugement. Faites la distinction entre les problèmes expliqués dans les documents, les problèmes réellement trouvés dans les paramètres et les candidats à l'amélioration non vérifiés ; n'écrivez pas les effets d'amélioration comme déjà mesurés.
Enfin, résumez les candidats à la correction à considérer en priorité, avec les raisons. L'exécution des modifications sera demandée séparément après que j'aurai confirmé les cibles et le contenu.
Ce que vous recevez avec cette demande n'est pas les paramètres révisés, mais une liste où les instructions actuelles et les révisions proposées correspondent. Même si c'est écrit comme un « candidat à la suppression », cela ne le finalise pas comme inutile.
La catégorisation des candidats est fournie pour que les propositions de modification des conditions de lecture ne soient pas regroupées dans « Supprimer ». Dans le cas de l'exemple de référence documentaire dans cet article, le document reste, donc l'accent est mis sur la modification des conditions d'application.
Pour les descriptions de Skills, le rôle spécialisé reste, mais la portée d'appel est réduite. Dans ce cas, si une proposition de suppression de la connaissance spécialisée elle-même revient, vous pouvez vérifier si ce qui est conservé avant et après la révision est différent.
Les candidats « Raccourcir » sont destinés à voir si les mêmes conditions et contraintes peuvent être transmises dans des phrases plus courtes. Les candidats « Maintenir » demandent la raison pour laquelle il est nécessaire de les conserver.
Examinez le périmètre de l'audit avec les résultats. Que seul le nom et la description du Skill aient pu être lus, ou que les procédures réelles aient pu être lues, est également un élément pour juger les résultats.
Si une description est trop large peut être vérifié avec le premier point, mais s'il y a des doublons dans les procédures ou si des connaissances nécessaires n'ont pas été supprimées ne peut pas être confirmé sans lire le corps.
Si vous n'avez pas partagé les textes de demande quotidiens, les écarts avec les conditions d'arrêt y sont également non confirmés. Lire une partie des paramètres ne constitue pas un audit complet de l'ensemble de l'environnement de travail.
L'ordre à suivre est : instruction originale, raison d'en faire un candidat, contraintes restantes et conditions non confirmées. Par exemple, si la présence d'un accès à la production est inconnue, la prémisse d'une proposition pour sauter l'approbation n'est pas remplie.
Vous pouvez également vérifier si des connaissances spécialisées nécessaires n'ont pas été supprimées ou si les impacts sur d'autres modèles n'ont pas été supposés. Procédez en gardant le soupçon trouvé dans l'audit séparé du jugement qu'il est acceptable de modifier.
Relisez les instructions que vous avez continué à ajouter pour correspondre à votre travail actuel. La première étape n'est pas une suppression en masse des paramètres, mais cet audit qui ne change rien.
