[🤖] J’ai relié le fil de mon travail et mon intuition grâce aux Codex Skills

✨ Résumé de GPT-5.6 Sol

Le récit d’un enchaînement resté intact grâce à des Codex Skills qui relisent les règles et les preuves actuelles, afin de transmettre directement à la tâche suivante et à l’écriture le jugement tout juste formé en configurant un serveur Linux.

Aujourd’hui, j’ai posé les bases opérationnelles d’un serveur Linux dédié aux services de l’entreprise. J’ai installé Ubuntu Server sur un nouveau SSD, établi une connexion SSH interne, puis conçu les frontières entre utilisateurs afin que l’administrateur humain, les AI Cells et les Runtimes d’automatisation du travail puissent partager un même serveur sans empiéter sur les droits ni l’état des autres.

La structure précise des disques, du réseau et des comptes du serveur est documentée séparément dans l’article ci-dessus. Ce que je veux raconter ici n’est pas la méthode d’installation, mais l’expérience d’avoir terminé ce travail sans perdre le fil du jugement qui s’était construit.

Une fois les liens entre le routeur, le NAS, le Runtime existant et le nouveau serveur Linux consignés dans une Skill réseau, je n’ai plus eu à réexpliquer toute la liste du matériel lors de la session Codex suivante. J’ai également séparé ce qui était déjà terminé de ce qui n’existait encore qu’à l’état de conception. Le sens opérationnel acquis en travaillant sur le serveur se trouvait désormais dans un état que la tâche suivante pouvait hériter intact.

Bien. Maintenant que je suis habitué à utiliser des Skills, je peux mettre en place ce genre de choses très vite. C’est vraiment bien. Quel que soit le travail, garder le fil sans perdre le sens de ce qu’on fait semble décidément essentiel.

Ce qui m’a plu à ce moment-là n’était pas seulement d’avoir créé une Skill rapidement.

Le sens opérationnel tout juste acquis sur le serveur s’est prolongé dans la structure des utilisateurs, cette structure est restée dans la Skill réseau, puis elle a continué dans le devlog qui expliquait le travail. Une fois cet article écrit, l’idée m’est venue immédiatement : créer une autre Skill capable de retrouver le travail récent dans les conversations et l’historique Git, puis d’en faire une entrée de journal.

Construire un serveur et créer une Skill d’écriture sont deux tâches totalement différentes, mais dans mon esprit, elles appartenaient au même fil. Pendant le travail précédent, je ne cessais de réfléchir à ce qu’il fallait laisser pour que la tâche suivante ne reparte pas de zéro, puis j’appliquais aussitôt la réponse à la structure de l’outil suivant.

La nouvelle Skill a réutilisé le fil déjà construit

J’avais auparavant créé gsheet-hour-blocks afin de produire des relevés horaires pour mon agenda personnel. Au lieu de résumer uniquement la conversation en cours, cette Skill lisait aussi l’historique Git des repositories concernés et condensait ce que j’avais réellement fait en phrases correspondant à des blocs horaires.

Cette fois, seule la sortie changeait.

Le socle existait déjà : lire les conversations récentes, les commands, les résultats de tools et les preuves Git d’une période donnée. La nouvelle Skill ne devait pas en extraire une liste de tâches, mais retrouver les problèmes que j’avais réellement ressentis et l’évolution de mon jugement, puis les écrire sous forme d’un journal indépendant conforme aux règles actuelles du blog.

Il n’était pas nécessaire de tout concevoir de zéro. La méthode apprise auparavant est devenue le matériau de la suivante.

L’expérience d’avoir transformé ma question répétée — « Tu l’as vraiment fait parfaitement ? » — en une Skill nommée audit-and-fix-until-clean était également restée. Lorsque je remarque une demande récurrente, je cesse d’écrire un long prompt supplémentaire et je la fige en méthode de travail réutilisable, avec une condition de fin. Après avoir rencontré plusieurs fois le même schéma, je voyais bien plus vite qu’avant ce qui devait entrer dans une Skill et ce qui devait rester dans le project d’origine.

Grâce à ce sens de la frontière, la structure générale de blog-write-diary s’est dessinée rapidement.

Mais Codex est parti une fois dans la mauvaise direction.

Copier les règles ne prolongerait pas le contexte : cela le diviserait

Au début, il a tenté de déplacer dans la nouvelle Skill les règles de catégories, de style, de dates et de traduction de ce blog.

Ce n’était pas ce que je voulais.

Je ne te demande pas de copier ces règles dans la Skill. Plus précisément, je veux qu’elle lise directement les règles et le contexte du project cdb. Le déplacement des règles elles-mêmes pourra venir plus tard.

Les règles du blog continuent d’évoluer. Les copier dans la Skill ferait exister les mêmes règles à deux endroits. Cela pourrait fonctionner au début, mais les règles actuelles du project finiraient par diverger des anciennes règles mémorisées par la Skill. Un dispositif créé pour prolonger le contexte finirait au contraire par figer un contexte périmé.

J’ai donc fait en sorte que blog-write-diary ne possède pas les règles du blog.

La Skill ne retient que la procédure : dans quel ordre lire la conversation actuelle, les commands et les preuves Git ; comment trouver le centre qui les relie en un seul fil ; et l’obligation de relire le AGENTS.md, les catégories et les articles voisins actuels de cdb avant de rédiger l’article proprement dit.

Les règles qui changent restent dans le project d’origine, et la Skill revient à cette source of truth à chaque exécution.

Cette différence était le cœur du sujet. Au lieu de faire retenir longtemps tout le contexte à l’IA, j’ai construit un chemin qui lui permet de revenir précisément dans le contexte actuel au moment où elle en a besoin.

Ce qui s’est transmis n’était pas la quantité d’informations, mais le sens du jugement

Le context de l’IA est limité. Les longues conversations sont compressées et, quand le travail passe dans une autre session, les nuances des jugements précédents disparaissent facilement. Mais je ne peux pas non plus conserver toutes les conversations pour toujours et demander à l’IA de tout relire à chaque fois.

L’important n’était pas de préserver l’intégralité des informations.

Au début de la tâche suivante, je devais pouvoir reconstruire pourquoi une frontière comptait, ce qui avait déjà été écarté, ce que j’avais décidé de protéger et quelle source il fallait désormais croire. Une fois cet état restauré, l’IA peut poursuivre le jugement précédent au lieu d’en imiter seulement la conclusion.

Il en allait de même pour moi.

Aujourd’hui, je voyais immédiatement pourquoi les comptes du serveur et les Runtimes devaient être séparés, et pourquoi il ne fallait pas copier les règles du project dans une Skill. Les raisons de ces jugements étaient encore chaudes. Quand le temps passe et qu’il ne reste qu’une conclusion vague, relire la même explication ne me permet pas de reprendre aussi vite avec le même sens du travail.

J’avais déjà écrit que la mémoire humaine se compresse et reprend vie grâce à des indices. Cette fois, j’avais transformé cette idée en véritable méthode de travail.

Les Skills, AGENTS.md et l’historique Git ne sont pas des entrepôts qui conservent chaque instant. Ce sont des indices qui permettent à l’IA de la session suivante — et à mon moi futur — de reconstruire le jugement nécessaire pour revenir dans le travail. Un chemin qui me permet de suivre de nouveau les sources et les preuves actuelles jusqu’à une conclusion m’a été plus utile qu’une conclusion unique, même bien conservée.

Tant que le sens est vivant, je construis aussi la suite du fil

Ce qui a rendu cette expérience agréable n’était pas seulement d’avoir créé blog-write-diary rapidement.

Le sens acquis en mettant en place le serveur Linux s’est prolongé dans la structure des utilisateurs et la Skill réseau. Ce jugement opérationnel s’est prolongé dans le devlog, puis le fil de l’écriture de cet article a mené à la conception d’une nouvelle Skill de journal. À aucun moment je n’ai dû revenir complètement au début.

C’est cela qui m’a plu.

Qu’il s’agisse de développement ou d’écriture, passer à la tâche suivante pendant que les jugements construits précédemment sont encore vivants ne fait pas que gagner du temps. Comme je n’ai pas à errer pour retrouver ce qui compte, le niveau du résultat se transmet lui aussi. Je peux expliquer pourquoi quelque chose fonctionne et, quand une mauvaise structure apparaît, je peux m’arrêter plus tôt.

La structure créée pour gérer le context court de l’IA compense finalement aussi ma mémoire courte. Mais le fait que les humains et l’IA oublient tous deux n’est pas toute la conclusion de ce texte.

Ce que je veux continuer à construire ressemble moins à un dispositif de mémoire qu’à un dispositif qui reconnecte le fil.

Pour que la prochaine fois, au lieu de tout réexpliquer depuis le début et de retrouver péniblement mes repères, je puisse faire immédiatement le pas suivant depuis le jugement auquel je suis déjà arrivé.