• Depuis l’onglet “Agents” de votre projet, cliquez sur le bouton “Créer un agent”.
• La fenêtre “Agent” s’ouvre : vous verrez un champ pour le nom de l’agent, un éditeur pour les steps (JSON) et des contrôles d’enregistrement/validation.
• Astuce : si vous partez d’un template existant, préférez la fonction “Dupliquer” (ou “Copier un template”) pour conserver une structure éprouvée.

• Remplissez le champ “Nom” par une courte phrase descriptive (ex. : “Générateur d’articles SEO depuis commits”).
• Si disponible, ajoutez une description qui précise l’objectif, les entrées attendues et les sorties produites.
• Pourquoi : un bon nom + description facilitent la maintenance et la réutilisation par d’autres membres de l’équipe.

• Dans l’éditeur JSON, définissez la liste d’étapes qui compose l’agent.
• Chaque étape doit contenir au minimum : un identifiant lisible, un type d’action (ex. LLM / transformation / sortie), un contenu de prompt ou d’instruction, et les cibles de sortie (ex. enregistrer, envoyer par email, webhook).
• Exemples conceptuels (forme simplifiée) :
  • Étape simple : {"id":"summarize","type":"llm","prompt":"Résume les changements..."}
  • Workflow dépendant : une étape B qui dépend de A peut référencer dependencies: ["stepA"].
• Règle pratique : donnez des IDs courts, sans espaces, et explicites (ex. generate_seo, extract_changelog).

• Cliquez sur le bouton “Valider” (ou “Vérifier la structure”) si la fenêtre le propose.
• Si l’outil signale des erreurs, lisez les messages : ils indiquent généralement la ligne et le champ problématique (synthaxe JSON, clé manquante, dépendance inconnue, etc.).
• Si l’éditeur n’offre pas de validation avancée, copiez le JSON dans un validateur JSON externe puis revérifiez les règles de dépendance et d’unicité d’ID.
• Si vous corrigez, relancez la validation jusqu’à obtention d’un statut “OK”.

• Une fois la validation réussie, cliquez sur “Enregistrer” ou “Sauvegarder”.
• Testez le comportement avec un run manuel si disponible : lancez l’agent sur un jeu d’exemples (un commit, un texte d’entrée) et vérifiez les documents générés et les sorties.
• Contrôlez les logs / sorties générées pour vous assurer que chaque étape produit le résultat attendu.
• Si le test échoue, revenez à l’éditeur, ajustez l’ordre des étapes, les prompts ou les dépendances, et répétez la validation.

• Après validation, associez l’agent à des hooks (déclencheurs Git ou planifiés) si nécessaire : cela active l’automatisation en production.
• Vérifiez les destinations de sortie (emails, webhook, enregistrement) pour vous assurer que les permissions et adresses sont correctes.
• Effectuez une exécution contrôlée (run manuel ou push de test) pour vérifier l’intégration complète.

Pour un premier agent, privilégiez un workflow en 2–3 étapes : ingérer l’entrée, demander au LLM de produire la sortie principale, puis sauvegarder/envoyer le résultat. Ainsi vous identifierez rapidement les ajustements nécessaires.

• Dans la liste d’agents, cliquez sur l’agent que vous voulez modifier puis sur le bouton “Éditer”.
• L’éditeur s’ouvre avec le nom, la description et le JSON des steps chargés.
• Astuce : si vous n’êtes pas sûr des changements, dupliquez l’agent avant modification pour disposer d’une version de secours.

• Pour ajouter une étape : insérez un nouveau bloc dans la liste des steps avec un ID unique et un rôle clair.
• Pour supprimer : retirez l’étape puis vérifiez que d’autres étapes ne dépendent pas d’elle.
• Pour modifier : changez le prompt, le type d’action ou les paramètres (p. ex. modèle cible, options de sortie).
• Toujours : gardez l’historique de vos modifications (versioning manuel via description ou duplication).

• Après modification, relancez la validation structurelle.
• Vérifiez explicitement :
  • que tous les IDs cités dans dependencies existent,
  • qu’il n’existe pas de cycle (A dépend de B et B dépend de A),
  • que le nombre total d’étapes reste raisonnable (voir bonnes pratiques).
• Si un message d’erreur indique un champ manquant, corrigez et relancez.

• Sauvegardez les changements.
• Lancez un run manuel ciblé (input de test) pour valider le comportement.
• Vérifiez les sorties et les logs. Si quelque chose ne correspond pas, revenez en arrière ou ajustez les prompts/paramètres.

• Assurez‑vous que le JSON est valide (parenthèses, virgules, guillemets).
• L’éditeur interne signale généralement une erreur de syntaxe ; corrigez avant toute autre vérification.

• Contrôles à effectuer :
  • Top‑level : la structure attendue est une liste/array d’étapes.
  • Chaque étape doit avoir un ID unique et une instruction/prompt.
  • Les dépendances doivent référencer des IDs existants.
  • Les types d’étapes doivent être supportés par votre projet (p. ex. type “llm”, “transform”, “output”).
  • Les champs optionnels (retries, timeout, metadata) doivent respecter les formats attendus.
• Utilisez les messages d’erreur fournis par l’éditeur pour corriger précisément.

• Petite checklist :
  • Pas de dépendances circulaires.
  • Pas d’étape orpheline si elle doit produire un élément clé.
  • Prompts concis : évitez d’envoyer l’intégralité d’un dépôt comme prompt.
  • Limitez le nombre d’étapes : au-delà d’une quinzaine d’étapes, la maintenance devient lourde.
• Si nécessaire, fractionnez un gros agent en plusieurs agents spécialisés qui s’appellent successivement.