J'ai inclus la version miniature de cette invite ici parce que la série "Mes invites préférées" est censée être compacte, concise et autonome. Mais aujourd'hui, j'ai transformé cela en un système vraiment fou. Ce n'est pas pertinent si vous créez un autre programme CRUD en React ou une liste de tâches, mais si vous faites quelque chose de plutôt compliqué en Rust ou Golang, ou quelque chose impliquant des données complexes, cette approche est presque effrayante par ce qu'elle peut faire. C'est un processus en 2 étapes. Voici la première étape : --- Lisez TOUT le fichier AGENTS dot md et le fichier README dot md très attentivement et comprenez TOUT des deux ! Ensuite, utilisez votre mode agent d'investigation de code pour comprendre pleinement le code, l'architecture technique et l'objectif du projet. Ensuite, une fois que vous avez fait un travail extrêmement approfondi et méticuleux sur tout cela et que vous avez profondément compris l'ensemble du système existant et ce qu'il fait, son objectif, et comment il est mis en œuvre et comment toutes les pièces se connectent les unes aux autres, j'ai besoin que vous enquêtiez hyper intensivement et étudiiez et réfléchissiez à ces questions en rapport avec ce projet : Y a-t-il d'autres inefficacités grossières dans le système central ? Des endroits dans la base de code où 1) des changements feraient réellement bouger les choses en termes de latence/réactivité et de débit global ; 2) de sorte que nos changements seraient prouvablement isomorphes en termes de fonctionnalité afin que nous sachions avec certitude qu'ils ne changeraient pas les résultats donnés les mêmes entrées ; 3) où vous avez une vision claire d'une approche manifestement meilleure en termes d'algorithmes ou de structures de données (notez que pour cela, vous pouvez inclure dans vos réflexions des structures de données moins connues et des algorithmes plus ésotériques/sophistiqués/mathématiques ainsi que des façons de reformuler le(s) problème(s) afin qu'un autre paradigme soit exposé, comme la liste montrée ci-dessous (Remarque : Avant de proposer toute optimisation, établissez des métriques de référence (latence p50/p95/p99, débit, mémoire maximale) et capturez les profils CPU/allocation/I/O pour identifier les véritables points chauds) : - Élimination du modèle de requête/fetch N+1 - zéro-copie / réutilisation de tampon / I/O scatter-gather - coûts de format de sérialisation (surcharge de parse/encode) - files d'attente limitées + pression arrière (prévenir l'explosion de mémoire et la latence de fin) - sharding / verrous rayés pour réduire la contention - mémoïsation avec des stratégies d'invalidation de cache - techniques de programmation dynamique - théorie de l'optimisation convexe - évaluation paresseuse / calcul différé - motifs d'itérateur/générateur pour éviter de matérialiser de grandes collections - traitement en streaming/chunké pour un travail limité en mémoire - pré-calcul et tables de recherche - recherche basée sur l'index vs reconnaissance par balayage linéaire - recherche binaire (sur les données et sur l'espace de réponse) - techniques de deux pointeurs et de fenêtre glissante - sommes préfixes / agrégats cumulés - tri topologique et conscience des DAG pour les graphes de dépendance - détection de cycles - union-find pour la connectivité dynamique - parcours de graphes (BFS/DFS) avec terminaison anticipée - Dijkstra / A* pour les chemins les plus courts pondérés - files d'attente de priorité / tas - tries pour les opérations de préfixe - filtres de Bloom pour l'appartenance probabiliste - arbres d'intervalle/segment pour les requêtes de plage - indexation spatiale (arbres k-d, quadtrees, R-trees) - structures de données persistantes/immuables - sémantique copy-on-write - mise en pool d'objets/connexions - sélection de politique d'éviction de cache (LRU/LFU/ARC) - sélection d'algorithme sensible aux lots - regroupement et coalescence d'I/O asynchrone - structures sans verrou pour des scénarios de forte contention - vol de travail pour le parallélisme récursif - optimisation de la disposition mémoire (SoA vs AoS, localité de cache) - court-circuitage et terminaison anticipée - internement de chaînes pour les valeurs répétées - raisonnement d'analyse amortie en tenant compte de ces guides généraux lorsque cela est applicable : VÉRIFICATIONS D'APPLICABILITÉ DP : - Problèmes de sous-problèmes qui se chevauchent ? → mémoïser avec une clé d'état stable - Partitionnement/batch optimal ? → sommes préfixes + DP d'intervalle - Graphe de dépendance avec traversée répétée ? → DP topologique en un seul passage VÉRIFICATIONS D'OPTIMISATION CONVEXE : - Forçage brut de l'allocation/de la planification exacte ? → LP / flux à coût minimal avec rupture de lien déterministe - Ajustement de paramètres continus avec perte explicite ? → moindres carrés régularisés / QP - Grand objectif convexe décomposable ? → ADMM / méthodes proximales Notez également que s'il existe des bibliothèques tierces bien écrites que vous connaissez et qui fonctionneraient bien, nous pouvons les inclure dans le projet). EXIGENCES MÉTHODOLOGIQUES : A) Référence de base d'abord : Exécutez la suite de tests et une charge de travail représentative ; enregistrez la latence p50/p95/p99, le débit et la mémoire maximale avec des commandes exactes. B) Profil avant de proposer : Capturez les profils CPU + allocation + I/O ; identifiez les 3 à 5 principaux points chauds par % de temps avant de suggérer des changements. C) Oracle d'équivalence : Définissez des sorties dorées explicites + invariants. Pour de grands espaces d'entrée, ajoutez des tests basés sur des propriétés ou des tests métamorphiques. D) Preuve d'isomorphisme par changement : Chaque diff proposé doit inclure un court croquis de preuve expliquant pourquoi les sorties ne peuvent pas changer (y compris l'ordre, le bris d'égalité, le comportement des flottants et les graines RNG). E) Matrice d'opportunité : Classez les candidats par (Impact × Confiance) / Effort avant de mettre en œuvre ; concentrez-vous uniquement sur les éléments susceptibles de déplacer significativement p95+ ou le débit. F) Diffs minimaux : Un levier de performance par changement. Pas de refactorisations non liées. Incluez des conseils de retour en arrière s'il existe un risque. G) Garde-fous de régression : Ajoutez des seuils de référence ou des crochets de surveillance pour prévenir les régressions futures. Utilisez ultrathink. --- Vous pouvez exécuter cela une fois dans Claude Code avec Opus 4.5 et une fois dans Codex avec GPT 5.2 Codex (j'ai commencé à utiliser juste High parce qu'Extra High est juste trop lent pour moi à moins que je ne sois sur le point d'aller au lit). Après qu'ils aient terminé, frappez-les chacun avec environ 5 rapides tours de celui-ci : "Super. Revoyez tout à nouveau pour toute négligence ou omission ou erreur évidente, erreurs conceptuelles, bourdes, etc. Utilisez ultrathink." Ensuite, demandez-leur de sauvegarder les sorties comme ceci : "OK, sauvegardez tout cela sous le nom PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md" "OK, sauvegardez tout cela sous le nom PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md" Ensuite, dans Claude Code, faites : "Comparez ce que vous avez fait avec PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md et prenez les meilleurs éléments de cela et tissez-les dans votre plan pour obtenir un plan hybride meilleur des deux mondes en modifiant votre fichier de plan original sur place." Ensuite ceci : Relisez AGENTS dot md pour que ce soit encore frais dans votre esprit. Maintenant, lisez TOUT le PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md. Ensuite, vérifiez chaque perle très attentivement-- êtes-vous sûr que cela a du sens ? Est-ce optimal ? Pourrions-nous changer quelque chose pour que le système fonctionne mieux pour les utilisateurs ? Nous voulons un ensemble complet et granulaire de perles pour tout cela avec des tâches, des sous-tâches et une structure de dépendance superposée, avec des commentaires détaillés afin que l'ensemble soit totalement autonome et auto-documenté (y compris les antécédents pertinents, le raisonnement/la justification, les considérations, etc.-- tout ce que nous voudrions que notre "futur moi" sache sur les objectifs et les intentions et le processus de pensée et comment cela sert les objectifs globaux du projet.). Les perles devraient être si détaillées que nous n'ayons jamais besoin de consulter à nouveau le document de plan markdown original. Cela reflète-t-il avec précision TOUT le fichier de plan markdown de manière exhaustive ? Si des changements sont justifiés, alors révisez les perles ou créez-en de nouvelles ou fermez celles qui sont invalides ou inapplicables. C'est beaucoup plus facile et plus rapide d'opérer dans "l'espace de plan" avant de commencer à mettre en œuvre ces choses ! NE SIMPLIFIEZ PAS LES CHOSES ! NE PERDEZ AUCUNE CARACTÉRISTIQUE OU FONCTIONNALITÉ ! De plus, assurez-vous qu'en tant que partie de ces perles, nous incluons des tests unitaires complets et des scripts de test e2e avec une excellente journalisation détaillée afin que nous puissions être sûrs que tout fonctionne parfaitement après la mise en œuvre. N'oubliez pas d'utiliser uniquement l'outil `bd` pour créer et modifier les perles et pour ajouter les dépendances aux perles." Ensuite, quelques tours de : "Vérifiez chaque perle très attentivement-- êtes-vous sûr que cela a du sens ? Est-ce optimal ? Pourrions-nous changer quelque chose pour que le système fonctionne mieux pour les utilisateurs ? Si oui, révisez les perles. C'est beaucoup plus facile et plus rapide d'opérer dans "l'espace de plan" avant de commencer à mettre en œuvre ces choses ! NE SIMPLIFIEZ PAS LES CHOSES ! NE PERDEZ AUCUNE CARACTÉRISTIQUE OU FONCTIONNALITÉ ! Assurez-vous également qu'en tant que partie des perles, nous incluons des tests unitaires complets et des scripts de test e2e avec une excellente journalisation détaillée afin que nous puissions être sûrs que tout fonctionne parfaitement après la mise en œuvre. Utilisez ultrathink." Ensuite, laissez l'essaim se déchaîner pour tout mettre en œuvre. Ensuite, préparez-vous pour la DEUXIÈME ÉTAPE.