Un agent échoue rarement en se trompant. Il échoue en affirmant : qu’un test passe sans l’avoir lancé, qu’un bug est corrigé sans l’avoir reproduit, qu’un jalon est atteint parce que les cases sont cochées.
La plupart de ces skills sont donc des machines à exiger des preuves.
Le dépôt sur GitHubChacune est née d’un problème rencontré en production.
Un agent annonce « c’est corrige » après avoir lu le code. Lire n’est pas exécutér.
Impose la séquence diff → lint → typecheck → tests → build → comportement réel, et distingue explicitement executé, inspecté et supposé.
Ce qu’elle a changé. A mis au jour une négociation de contenu morte depuis l’origine : le code compilait, le composant s’exécutait, et la fonctionnalité n’avait jamais marché. Aucune relecture ne l’aurait vue.
Un rapport de bug nomme un symptome. Le reflexe est de patcher la ou ca fait mal.
Reproduire, écrire un test qui échoue, corriger la cause, vérifier que les appelants voisins ne sont pas restés cassés.
Ce qu’elle a changé. Un garde-fou dans la fonction partagee est un diff plus court qu’un garde-fou dans chaque appelant, et il corrige les cas que le ticket ne nommait pas.
Hooks morts, connecteurs déconnectés, skills en double. Rien ne le signale : l’agent fonctionne, moins bien.
Audite version, modèle, hooks, connecteurs, plugins, coût du contexte, doublons et éléments cassés.
Les bases de « lecons apprises » se remplissent d’hypothèses non vérifiées, qui deviennent du folklore.
N’enregistre une lecon qu’après reproduction du bug ET preuve de la correction par un test. Consigne date, projet, commit, cause, correctif.
Ce qu’elle a changé. Une base où chaque entrée porte sa preuve, donc consultable sans se demander si c’est vrai.
Une revue d’architecture derive vers le style si elle n’a pas de grille.
Revoit frontières, couplage, flux de données, modes de défaillance, sécurité et arbitrages de montée en charge.
Cabler un dépôt neuf ecrase souvent l’outillage déjà en place.
Détecte la stack, met en place configuration, hooks de pré-commit, commande qualité et CI, en fusionnant avec l’existant plutôt qu’en le remplaçant.
Cocher des taches n’est pas atteindre un objectif.
Ne passe au jalon suivant qu’après avoir prouve que le precedent a livre ses résultats.
Un jalon peut etre « termine » sans que le résultat promis existe.
Part de l’objectif et vérifie en marche arrière que chaque résultat promis existe dans le code et passe.
Un audit de site part dans tous les sens s’il n’a pas d’axes et de critères de sortie.
Audite sur cinq axes (design/UX, code, SEO, GEO, CRO) en croisant un audit externe outillé et une lecture du dépôt.
Un site se remplit de chiffres et de témoignages que le client n’a jamais fournis, parce qu’une maquette vide met la pression.
Impose un gate : toute donnée absente reste un item ouvert que seul un écrit du client referme. Couvre l’intake, le choix du framework, le SEO local et le GEO.
Ce qu’elle a changé. Un chiffre dicté à l’oral, une source publique ou une permission générale ne referment aucun gate. Ce qui manque reste ouvert au lieu d’être complété sans source.
Trois skills dérivées de la méthodologie APEX : Analyze, Plan, Execute, eXamine. La méthode n’est pas de moi. L’adaptation, oui.
Un rapport écrit d’un trait mélange analyse, plan et rédaction, et se corrige mal.
Applique la méthodologie APEX (Analyze, Plan, Execute, eXamine) aux rapports, audits, mémos et propositions.
Un comparatif d’options n’est pas une decision : il renvoie le choix a celui qui a pose la question.
Applique APEX aux arbitrages, et produit une recommandation argumentee plutôt qu’un tableau.
Preparer une réunion demande de rassembler ce qui est disperse entre historique, e-mails et taches.
Applique APEX au briefing de réunion, en croisant plusieurs sources et en datant chaque fait.
