Aller au contenu
learn
Menu global

AutoHarness, des skills qui s'écrivent seuls pour Claude Code — Mission

Pourquoi j’apprends cela

Section intitulée « Pourquoi j’apprends cela »

Le cours de programmation agentique a présenté les pièces que Claude Code te donne : hooks, skills, sous-agents, serveurs MCP. Tu écris un skill, tu le commites, et il reste ce que tu as écrit. AutoHarness te prend la plume. Il observe tes sessions par des hooks, demande à un modèle en arrière-plan de distiller ce qui s’est passé en skills, les dépose dans .claude/skills/ sans demander, puis archive plus tard ceux qui ne servent plus. Son README promet qu’il « stays clean on its own » (reste propre tout seul), en ne touchant « only the skills it wrote itself » (qu’aux skills qu’il a écrits lui-même).

Un outil qui écrit des instructions que ta prochaine session « MUST consider » (doit envisager) mérite plus d’examen qu’un outil qui se contente de lire. Et chacune de ses promesses se teste : la partie qui décide de ce qui arrive sur le disque est du Python ordinaire, qui tourne sans modèle. Ce cours fait donc ce que le cours SlashForge a fait avec un installeur, un cran plus loin : il lit le code épinglé, écrit à quoi ressemblerait chaque promesse si elle était fausse, puis exécute le code face à ces prédictions, dans un labo où rien ne peut atteindre le vrai ~/.claude.

À qui s’adresse ce cours

Section intitulée « À qui s’adresse ce cours »

Tu écris du C# ou du Java, tu utilises Claude Code et tu sais ce que sont un hook et un skill — le cours de programmation agentique jusqu’à sa leçon 3 suffit —, et tu te demandes s’il faut laisser un outil réécrire les instructions de ton agent à ta place. Pas besoin de bien connaître Python : le code du labo est court, et chaque ligne de sortie est expliquée.

Une couche de skills qui se modifie elle-même, en termes .NET et Java

Section intitulée « Une couche de skills qui se modifie elle-même, en termes .NET et Java »
.NET / Java AutoHarness
Distribution un paquet NuGet ou Maven un plugin Claude Code : des hooks, deux agents, un serveur MCP, du code Python
Quand il s’exécute quand tu l’appelles à chaque appel d’outil, à chaque tour et à chaque début de session, par des hooks
Ce qu’il produit des assemblies que tu livres des skills en Markdown que les sessions suivantes chargent
Qui écrit le résultat toi, relu dans une pull request un claude -p en arrière-plan sur Haiku, puis un promoteur déterministe qui le dépose — sans étape de relecture
Propriété l’auteur d’un fichier dans git blame un .sidecar.json à côté du skill qui dit "created_by": "agent"
Nettoyage tu supprimes le code mort les skills inutilisés assez longtemps sont archivés automatiquement

C’est la cinquième ligne qui occupe la plus grande partie de ce cours. Un simple fichier JSON décide de ce qu’AutoHarness considère comme sien, et la question est ce qui se passe autour de cette décision.

À la fin de ce cours, je saurai

Section intitulée « À la fin de ce cours, je saurai »
  • dire quels événements font capturer, réfléchir, promouvoir, injecter et archiver AutoHarness, et lesquels font intervenir un modèle ;
  • exécuter la partie d’un outil qui n’a pas besoin de modèle dans des sous-processus isolés, avec un répertoire personnel jetable et un environnement construit à partir de rien ;
  • préinscrire une fixture — question, hypothèse, témoin, falsificateur, empreinte des entrées — avant de l’exécuter, et garder ce qui revient même quand ça me donne tort ;
  • distinguer ce qu’affirme un README, ce que montre le code, ce que reproduit une fixture et ce que seul un modèle en direct pourrait dire ;
  • décider, preuves à l’appui, s’il faut laisser un tel outil toucher un vrai projet.

Plan

Section intitulée « Plan »
# Leçon Tu connais déjà
1 Un labo de fixtures : six promesses testées sans installer un test unitaire avec un faux, un test qui doit d’abord échouer, un environnement de test propre
2 Prévue : la boucle et ses frontières d’autorité — hooks, reflector, promoteur, et ce qu’un dépôt cloné peut mettre en file un job en arrière-plan, un compte de service, un pipeline de déploiement sans étape d’approbation
3 Prévue : pourquoi l’usage n’est pas la qualité — compteurs, maturité et capacité la couverture de code comme métrique, un feature flag que personne ne retire
4 Prévue : plantages, concurrence et historique — ce qui survit à une promotion interrompue une file « au moins une fois », une mise à jour perdue, une sauvegarde qui écrase la précédente
5 Prévue : l’évaluation et une liste de contrôle d’adoption une preuve de concept, une revue go/no-go
— Journal

Les leçons 2 à 5 sont prévues, pas écrites. Leurs hypothèses sont déjà listées dans l’évaluation (§2, read in the source, not run), et chacune demandera ses propres fixtures préinscrites avant d’affirmer quoi que ce soit.

Ressources

Section intitulée « Ressources »