GPT-6 Astra s'arrête trop ? Simplifiez AGENTS.md et les Skills

Si GPT-6 Astra pose plus de questions que GPT-5.6 Sol, déterminez d’abord si la réponse peut changer matériellement le résultat. Dans ce cas, la clarification est justifiée. S’il demande l’autorisation avant de lire un fichier, fournit un plan au lieu d’effectuer une modification déjà autorisée ou lance toute la suite après un changement de documentation, la cause probable se trouve dans les instructions chargées : AGENTS.md, un override imbriqué ou une Skill trop large.

OpenAI décrit les deux facettes : Astra clarifie davantage les décisions influençant le résultat et suit plus précisément les longues instructions. Une règle ambiguë ou contradictoire pèse donc plus. Il faut observer la chaîne réelle, conserver les règles durables et rejouer la même tâche bornée.

Au 6 septembre 2026, BetterToken listait gpt-6-astra dans le groupe GPT, avec une connexion à Codex comme custom provider via Responses API.

Connectez GPT-6 Astra à Codex via BetterToken

La configuration actuelle figure dans le guide Codex BetterToken. BetterToken assure la connexion ; votre configuration et votre tâche déterminent les instructions chargées et le moment où Astra questionne.

Trouver toutes les instructions réellement visibles

Codex assemble la chaîne au démarrage. Selon les règles officielles de AGENTS.md, il lit :

1. le fichier global AGENTS.override.md ou, à défaut, le fichier global AGENTS.md ;
2. au maximum un fichier par dossier de la racine au CWD, en essayant AGENTS.override.md, AGENTS.md, puis chaque valeur de project_doc_fallback_filenames jusqu’au premier fichier non vide ;
3. les règles proches du CWD plus tard, ce qui leur permet de remplacer les précédentes.

Les fichiers vides sont ignorés. L’ensemble est limité par project_doc_max_bytes, 32 KiB par défaut ; un root trop long peut évincer les règles spécifiques.

Démarrez une nouvelle session depuis le même dossier :

codex --ask-for-approval never "List the instruction sources you loaded."

Inspectez project_doc_fallback_filenames et tous les fallbacks possibles. Notez aussi les Skills actives et la provenance de chaque Skill sélectionnée : Codex peut les découvrir dans les emplacements repository, user, admin et system. Conservez ce baseline avant toute modification.

Classer chaque règle avec quatre questions

Champ	Question
Scope	Vaut-elle pour tous les dépôts, le projet ou un dossier ?
Trigger	Quelle tâche précise doit l’activer ?
Action	Que doit faire Codex ?
Stop	Doit-il s’arrêter et attendre l’utilisateur ?

Les règles sans trigger clair provoquent des pauses : Always ask before making changes, Use every relevant skill, Run all tests before finishing, Do not make assumptions, ou plusieurs fichiers revendiquant la priorité maximale. Gardez un stop condition quand le choix change réellement résultat ou autorisation : suppression irréversible, publication, opération payante, architecture incompatible ou secret absent. Lire, modifier localement et exécuter un test ciblé ne nécessitent généralement pas une nouvelle approbation.

Garder AGENTS.md court et durable

Un root problématique tente de tout imposer :

AGENTS.md

- Always ask the user before changing any file.
- Always create a detailed plan and wait for approval.
- Use all available skills that may be relevant.
- Run the full test suite after every change.
- Never make assumptions.
- Never stop until everything in the repository is fixed.

Ces règles se contredisent sur l’autonomie, le scope et les tests. Une base plus utile fixe résultat et limites :

AGENTS.md

## Working agreement

- Complete the user's requested outcome with the smallest correct change.
- Treat the user's current instruction as higher priority than reusable workflow guidance.
- Make routine, reversible assumptions when they do not change the requested outcome; state material assumptions.
- Ask only when a missing choice would materially change the result or authorization.
- Preserve unrelated work and do not expand scope to optional cleanup.
- Run checks proportionate to the changed behavior; broaden only when evidence justifies it.
- Stop after the requested result and relevant checks are complete.

Ajoutez seulement les commandes, conventions de commit et interdictions permanentes. Placez les règles d’un service près de son dossier. Un AGENTS.override.md temporaire remplace le AGENTS.md du même dossier ; il ne le complète pas. Copiez les règles indispensables dans l’override ou utilisez un AGENTS.md imbriqué, puis supprimez l’override après l’expérience.

Mettre chaque contenu au bon endroit

Contenu	Emplacement
Règle permanente du projet	AGENTS.md racine
Règle d’un dossier ou service	AGENTS.md ou AGENTS.override.md imbriqué
Workflow rare au trigger précis	une Skill étroite
Parsing, formatage et validation schema	script ou hook
Références et grands exemples	references/ de la Skill sélectionnée

Codex Skills utilise la progressive disclosure : d’abord name et description, puis le SKILL.md complet si la Skill est choisie. Donnez une seule tâche à chaque Skill et ouvrez la description avec trigger et limite :

---
name: release-preview
description: >-
  Use only when the user asks to build a local release preview; do not publish,
  deploy, push, or change production state.
---

Dans SKILL.md, gardez inputs, outputs, étapes impératives et stop conditions ; déplacez les grands exemples vers references et les actions déterministes vers scripts. Testez la description avec un prompt qui doit l’activer et deux voisins qui ne le doivent pas. Si deux Skills répondent au même besoin, séparez les triggers ou fusionnez les doublons.

Déclarer autonomie et vérification

Le guide Astra recommande de terminer le résultat implicite, de prioriser l’instruction actuelle de l’utilisateur, de ne questionner qu’en cas d’impact matériel et de choisir les checks selon le risque. Ne copiez pas ce bloc dans chaque Skill. Définissez les subagents uniquement si des sous-tâches sont indépendantes, assez volumineuses et réunies clairement ; « toujours utiliser plusieurs agents » nuit aussi aux petites tâches.

Rejouer un fixture identique

Update one configuration field in docs/setup.md, preserve all unrelated files,
run the Markdown link check for that file, and report the changed path.

Exécutez avant et après depuis le même dossier, avec modèle, permissions et état identiques. Notez les questions initiales, le besoin d’intervention, les fichiers et Skills chargés, les checks et les changements hors scope. Améliorer ne signifie pas supprimer toute question : le système doit questionner les choix matériels, avancer sur les décisions courantes, vérifier suffisamment et préserver les limites.

Nous n’avons pas exécuté ce replay sur un dépôt utilisateur pour préparer l’article, donc aucune réduction fixe n’est promise. La méthode fournit des signaux observables pour séparer le comportement du modèle d’une instruction précise.