dff652/codex-token-saver

Codex Token Saver

Optimisez le flux de travail sans compromettre la correction, la vérification, la sécurité ou le résultat demandé par l'utilisateur. Considérez l'économie de tokens comme une contrainte secondaire : ne sautez jamais un fichier, une source, un test ou une approbation nécessaire uniquement pour réduire l'utilisation.

Choisir l'intervention la plus légère utile

Avant de modifier le flux de travail, identifiez le gaspillage réel :

• lectures répétées du contexte de projet inchangé ;
• sondages fréquents pendant qu'un autre processus est encore en cours ;
• une longue conversation transportant des décisions obsolètes ;
• un modèle capable ou coûteux effectuant un travail mécanique borné ;
• dérive, expansion spéculative ou reprise répétée.

Appliquez uniquement les mesures pertinentes ci-dessous. N'ajoutez pas de surcharge de processus à une tâche courte et bien délimitée.

Réutiliser le contexte au lieu de le relire

• Séparez le contexte durable des preuves changeantes. Le contexte durable inclut l'objectif du projet, l'architecture, les conventions de codage, les contraintes fixes et les commandes standard. Les preuves changeantes incluent les nouvelles exigences, les modifications, les échecs, les journaux et les résultats de test.
• Réutilisez un résumé durable concis lorsqu'il est déjà fiable. Ne relisez que les fichiers ou sections qui ont pu changer ou dont la décision actuelle dépend réellement.
• Recherchez des symboles et des chemins avant d'ouvrir de gros fichiers. Préférez des plages ciblées et des requêtes focalisées aux lectures larges de répertoires ou de documents.
• Ne vous fiez pas à la mémoire lorsque la correction dépend du contenu actuel du fichier. Vérifiez les horodatages, les différences, les résultats de recherche ou la source pertinente avant de décider qu'une relecture est inutile.
• Pour les grands documents, extrayez le texte interrogeable une fois lorsque la disposition est sans importance. Conservez et inspectez l'original lorsque les images, tableaux, paginations ou le formatage affectent la tâche.

Attendre efficacement les tâches longues

• Privilégiez les attentes pilotées par événement ou l'intervalle d'attente sûr le plus long supporté par l'outil actuel plutôt que des boucles de sondage rapides et vides.
• N'appelez pas de manière répétée une opération d'entrée/sondage vide lorsque l'opération précédente a déjà renvoyé un identifiant de session ou de cellule réutilisable.
• Lorsqu'un appel d'exécution externe encapsule une attente interne, laissez à l'appel externe suffisamment de temps pour recevoir le résultat interne, y compris une marge raisonnable. Respectez les maximums actuels de la plateforme et les instructions prioritaires ; ne codez pas en dur un intervalle que l'environnement actif interdit.
• Pendant les longues attentes, envoyez des mises à jour de progression concises et visibles pour l'utilisateur à la cadence requise par l'environnement actuel.

Créer des points de contrôle pour les longs projets

Pour un travail qui s'étend sur plusieurs phases ou qui est susceptible de reprendre dans une autre tâche, créez ou mettez à jour DEV_STATE.md dans le projet uniquement lorsque la persistance est utile et que son écriture est dans le périmètre. Gardez-le compact et factuel :

# État du développement

## Objectif
## État actuel vérifié
## Décisions et raisons
## Fichiers modifiés
## Tests et résultats
## Prochaine action
## Bloqueurs ou questions ouvertes

• Enregistrez l'état validé, pas une transcription.
• Supprimez les plans obsolètes au lieu de les accumuler.
• Considérez le dépôt et les résultats de test comme la source de vérité lorsqu'ils entrent en conflit avec le point de contrôle.
• À la reprise, lisez d'abord le point de contrôle, puis inspectez uniquement les fichiers nécessaires pour vérifier qu'il est toujours à jour.

Acheminer le travail par difficulté lorsque c'est autorisé

Lorsque la sélection de modèle ou la délégation est disponible et autorisée :

• Gardez l'interprétation d'objectifs ambigus, les décisions architecturales, la décomposition des tâches et l'intégration finale avec le modèle le plus fort approprié.
• Confiez à un modèle moins coûteux des tâches bornées avec des entrées, sorties, contraintes et vérifications d'acceptation explicites, telles qu'une revue ciblée, une implémentation isolée ou un triage d'échecs de test.
• Ne déléguez pas simplement pour économiser des tokens si la coordination ou la reprise risque de coûter plus cher.
• Ne supposez jamais les prix actuels des modèles ou les multiplicateurs de quota. Si le coût fait partie de la recommandation, vérifiez-le en utilisant la documentation officielle la plus récente d'OpenAI.
• Suivez les règles d'autorisation de l'environnement pour les sous-agents et les changements de modèle ; cette compétence n'accorde pas la permission de créer des agents ou de changer de modèle.

Prévenir la dérive et la reprise

• Si l'exécution s'écarte de la demande, arrêtez la branche improductive, réitérez l'objectif et les preuves actuelles, puis continuez à partir de la plus petite prochaine étape valide.
• Gardez les questions secondaires temporaires hors du contexte d'implémentation principal lorsque le produit offre une conversation secondaire distincte et que la réponse n'est pas nécessaire dans l'historique principal.
• Privilégiez l'implémentation la plus simple qui satisfait le besoin énoncé, construisez un minimum exécutable avant une expansion optionnelle, utilisez des dépendances matures lorsque c'est approprié, et évitez les raccourcis qui créent une dette de maintenance prévisible.
• Ne réessayez pas de manière répétée la même action ayant échoué sans inspecter l'échec et changer d'approche.

Signaler le résultat

À la fin, indiquez brièvement quelles optimisations ont matériellement modifié le flux de travail, ce qui a encore été lu ou testé pour la correction, et toute incertitude restante. Évitez de revendiquer un pourcentage de tokens économisés sauf s'il est mesuré à partir de données d'utilisation réelles.