Construire un Agent

Transformez une tâche que le propriétaire fait chaque semaine en quelque chose qu'il demande par son nom.

C'est ce qui empêche le plugin d'avoir à livrer le workflow de chaque secteur. Aucun catalogue ne peut couvrir la routine de permis d'un entrepreneur en fosse septique ou la réconciliation des commissions de transporteur d'une agence d'assurance. Ces propriétaires peuvent les construire.

Étape 1 — Regardez-la se dérouler, ou écoutez-la être décrite

Deux points de départ, et le premier est bien meilleur.

Meilleur : ils viennent de le faire dans cette conversation. Si le propriétaire a parcouru la tâche avec vous — tiré les fichiers, pris les décisions, vous a corrigé deux fois — cette transcription est la spécification. Extrayez-la plutôt que de les réintéroger. Les corrections qu'ils ont apportées sont la partie la plus précieuse, car elles encodent un jugement que le propriétaire n'aurait jamais pensé à énoncer.

Sinon : ils la décrivent. Demandez-leur de retracer la dernière fois qu'ils l'ont fait, concrètement. Des détails réels battent toujours une description abstraite — « mardi dernier j'ai tiré le fichier du transporteur, l'ai comparé à ce qu'on avait enregistré, et j'ai suivi six écarts » vous en dit plus que « je réconcilie les commissions ».

Consultez reference/capture.md pour savoir comment obtenir une image complète sans interrogatoire.

Étape 2 — Séparez ce qui varie de ce qui reste fixe

C'est tout l'art de cette étape. Une skill qui code en dur les spécificités de mardi dernier ne fonctionne que mardi dernier.

Pour chaque partie de la tâche, décidez :

• Fixe — la séquence, les sources, le format de sortie, les règles
• Varie — les dates, les noms, les montants, quel fichier, quel client
• Jugement — les parties où le propriétaire décide, qui deviennent des portes d'approbation

Les corrections que le propriétaire a apportées en la parcourant marquent généralement les points de jugement. Quand quelqu'un dit « non, pas celui-là — on saute tout ce qui est sous 50 USD », c'est une règle. Quand il dit « hmm, ça dépend », c'est une porte d'approbation.

Étape 3 — Trouvez les portes d'approbation

Chaque étape qui envoie, dépense, publie ou supprime a besoin d'une porte. Il en va de même pour chaque étape où le propriétaire a hésité.

Ne bloquez pas tout — une skill qui demande neuf fois la permission est pire que de le faire à la main. Bloquez ce qui est conséquent et ce qui est ambigu, et laissez le reste fonctionner.

Consultez reference/skill_authoring.md pour savoir où les portes doivent être et comment les formuler.

Étape 4 — Écrivez-la

Produisez une véritable skill dans la même forme que tout le reste dans ce plugin : un SKILL.md avec du frontmatter et des étapes numérotées, plus un dossier reference/ si le détail le justifie.

Les exigences qu'elle doit respecter, comme chaque skill livrée :

• Le nom et le dossier correspondent, minuscules avec traits d'union
• La description dit ce qu'elle fait et quand la déclencher, à la troisième personne
• Un vrai repli pour quand un connecteur manque
• Des portes d'approbation sur tout ce qui est conséquent
• Ne jamais invente un nombre ; les données manquantes sont signalées comme manquantes

Écrivez-la selon les termes du propriétaire, pas en langage commercial générique. S'il l'appelle « le fichier du transporteur », la skill dit fichier du transporteur. Une skill remplie de vocabulaire inconnu est une qu'il ne fera pas tourner sans surveillance.

Étape 5 — Testez-la sur un cas réel, avant qu'il s'y fie

Exécutez la nouvelle skill sur un cas dont le propriétaire connaît déjà la réponse — idéalement celui exact qu'il a parcouru. Montrez la sortie à côté de ce qu'il a obtenu à la main.

C'est cette étape qui détermine si la skill sera utilisée. Un propriétaire qui l'a vue reproduire un résultat connu bon la programmera. Un qui ne l'a pas vu l'exécutera manuellement et la vérifiera chaque fois, ce qui ne sauve rien.

Si ça ne correspond pas, corrigez la skill et exécutez-la à nouveau. Ne demandez pas au propriétaire d'accepter un résultat approximatif.

Étape 6 — Enregistrez et définissez la cadence

Ajoutez-la à smb-router pour que les demandes en anglais courant la trouvent, et enregistrez les phrases de déclenchement que le propriétaire utilise réellement.

Si c'est une tâche récurrente, proposez de la programmer. La programmation est ce qui convertit « une skill que je pourrais exécuter » en « quelque chose qui se passe sans moi », qui est le résultat qu'il voulait.

Étape 7 — Partagez-la, avec approbation

Proposez de partager avec l'équipe. Dites ce que partager signifie : qui l'obtient, quelles données elle peut atteindre, et ce qu'elle peut faire sans surveillance.

Soyez spécifique sur le risque quand une skill envoie, dépense ou écrit. Une skill qui envoie des emails à des clients, exécutée pour quelqu'un qui ne l'a pas construite et ne connaît pas ses hypothèses, est un vrai danger. Recommandez brouillon uniquement pour les skills partagées qui envoient quelque chose.

Ce qu'il ne faut pas faire

• Ne réintérogez pas sur une tâche qu'ils viennent de parcourir. La transcription est la spec.
• Ne codez pas en dur l'exemple. Les noms, dates et montants varient ; la séquence ne varie pas.
• Ne bloquez pas chaque étape. Neuf approbations c'est pire que de le faire à la main.
• Ne sautez pas la exécution de test. Une skill non testée est vérifiée manuellement pour toujours, ce qui ne sauve rien.
• Ne l'écrivez pas en langage commercial générique. Leurs mots, ou ils ne lui feront pas confiance.
• Ne construisez pas quelque chose qui envoie ou dépense sans portes d'approbation. Jamais, peu importe ce que le propriétaire demande.

Après la construction

Le propriétaire a maintenant une skill nommée qu'il peut déclencher ou programmer. Si la nouvelle skill a rencontré un outil qui n'est pas connecté, « me connecter à mon ERP » (build-connector) est l'étape naturelle suivante — cela transforme le système manquant en source fonctionnelle. À proximité aussi : « me briefer » pour intégrer la nouvelle sortie dans le tableau quotidien, et « brief du lundi » si la skill doit alimenter celle hebdomadaire. Proposez au maximum trois, et ignorez toute offre que le propriétaire a déjà déclinée cette session.

Fichiers de référence

• reference/capture.md — obtenir une image complète de la tâche sans interrogatoire
• reference/skill_authoring.md — la structure, le frontmatter, et où les portes d'approbation doivent être
• reference/gotchas.md — les modes de défaillance qui produisent une skill que personne n'utilise