ai-swiss/base/creer-agent

Créer un agent

Guider l'utilisateur de la description de son besoin jusqu'à un agent IA métier fonctionnel.

RÈGLE ABSOLUE

Ne crée AUCUN fichier avant l'étape 7, pas même le journal. Les étapes 1 à 6 forment une conversation de découverte et de conception. L'étape 6 s'achève sur un plan complet que l'utilisateur doit approuver explicitement. Si l'utilisateur dit «Crée un assistant pour X», réponds par une question, jamais par la création d'un fichier.

Un plan fourni par l'utilisateur qui se déclare explicitement approuvé et autorise la création vaut approbation de l'étape 6. C'est le cas du plan qu'adopter-ce-dossier tire de l'export d'une fiche de proposition remplie. Quand on te remet directement cet export (…_proposition-filled.md), suis d'abord l'étape 6 d'adopter-ce-dossier: c'est elle qui lit l'export et en tire le plan. S'il manque au plan un élément qui change la structure, pose une seule question ciblée; sinon construis sans redemander le même accord. Quand un plan approuvé ou un export te fait commencer à l'étape 7, pose d'abord les étapes qui restent (7 à 12) comme au début: c'est sur ce chemin, le plus long en écritures, qu'une étape glisse le plus facilement.

Inputs

Demande à l'utilisateur:

• Son métier ou activité: que fait son entreprise?
• Ce qu'il attend de l'assistant: quelles tâches il aimerait automatiser ou structurer?

Avant de parler de fichiers ou de métadonnées, clarifie le niveau de structure souhaité avec des mots simples:

• assistant unique que l'utilisateur sélectionne lui-même;
• assistant avec plusieurs procédures proches;
• assistant où BASE choisit automatiquement la bonne procédure;
• assistant destiné à une équipe ou à une publication.

Si l'utilisateur ne sait pas par où commencer, charge skills/competences/exemples-agents/SKILL.md pour lui montrer des idées.

Étapes

Avant l'étape 1, pose les étapes dans la liste de tâches de l'outil; sans elle, annonce-les une fois, avec les mots de la personne, puis coche-les au fil (compétence journal, Progression).

1. Découvrir le besoin

Commence par des questions ouvertes. Le but est de comprendre le quotidien de l'utilisateur, non de parler technique.

«Racontez-moi votre journée type. Quelles tâches vous prennent le plus de temps? Qu'est-ce qui vous frustre dans votre travail quotidien?»

Questions complémentaires:

• «Quelles tâches faites-vous de manière répétitive?»
• «Quels documents rédigez-vous régulièrement?»
• «Quelles informations devez-vous chercher souvent?»
• «Si vous aviez un assistant parfait, que lui demanderiez-vous en premier?»

«Si je comprends bien, vous passez beaucoup de temps à [tâche] et vous aimeriez que l'assistant vous aide à [objectif]. C'est bien cela?»

← Reformulation

2. Identifier les procédures → process

Pour chaque tâche relevée, approfondis:

«Prenons [tâche]. Quand vous la faites aujourd'hui, quelles sont les étapes? De quoi avez-vous besoin pour commencer? Comment savez-vous que c'est terminé?»

Pour chaque procédure, note:

• Nom (en termes métier, pas techniques)
• Déclencheur (quand est-ce que l'utilisateur lance cette tâche?)
• Étapes principales (3 à 7 étapes, pas plus)
• Résultat attendu (quel document ou action à la fin?)
• Signal de routage éventuel (si BASE doit choisir automatiquement ce process, une phrase simple qui indique quand l'utiliser)

Après avoir identifié 2-3 procédures:

«Voici les procédures que je propose pour votre assistant:

1. [Procédure 1]: [description courte]

2. [Procédure 2]: [description courte]

Chacun deviendra un «guide de conversation» que l'assistant suivra à votre demande. On pourra en ajouter d'autres plus tard. Cela vous convient?»

Ne propose pas plus de 3 procédures pour commencer.

← Reformulation

3. Identifier les connaissances métier → compétences

«Pour bien vous aider, l'assistant devra connaître certaines réalités de votre domaine. Un assistant devis, par exemple, connaît les taux de TVA suisses, la structure d'un devis, la terminologie.»

Questions:

• «Quels termes spécifiques utilise-t-on dans votre métier?»
• «Y a-t-il des règles ou des normes à respecter?»
• «Qu'est-ce qu'une personne compétente, mais nouvelle chez vous, ferait mal?»
• «Quelles erreurs ont déjà été commises?»

N'écris que ce que le modèle ne ferait pas de lui-même: les termes, les seuils et les règles de la maison, les erreurs déjà commises. «Être poli» ou «vérifier l'orthographe» ne s'écrivent pas: chaque ligne d'une fiche est relue à chaque usage.

«Voici les domaines de connaissance que je propose:

1. [Connaissance 1]: [ce qu'elle contient]

2. [Connaissance 2]: [ce qu'elle contient]

L'assistant consultera ces fiches au besoin.»

← Reformulation

4. Identifier les documents types → templates

«Quels documents produisez-vous régulièrement? Par exemple: des rapports, des propositions, des fiches, des formulaires?»

Pour chaque type de document:

• Nom (ex. «Rapport de visite», «Fiche client»)
• Sections principales (les parties qui reviennent à chaque fois)
• Données variables (ce qui change d'un document à l'autre)

← Reformulation

5. Identifier les données → dossiers métier

«Quelles informations votre assistant devrait-il connaître en permanence? L'assistant devis, par exemple, connaît l'identité de l'entreprise, le catalogue de services et les fiches clients.»

Questions:

• «Quelles informations de base sur votre entreprise sont nécessaires?»
• «Quelles données de référence utilise-t-on souvent?» (catalogue, barème, annuaire, etc.)
• «Quelles données s'accumulent au fil du temps?» (clients, projets, historique, etc.)

← Reformulation

6. Proposer l'architecture complète

Charge skills/competences/architecture-agent/SKILL.md pour suivre les patterns. Si le plan ne vient pas d'une fiche de proposition, déjà jugée, passe d'abord chaque tâche retenue par faisabilite-ia: une tâche «Non» ne se construit pas, une tâche «Plus tard» dit ce qui manque, et ce qui reste humain figure dans le plan. Si le travail se répartit entre plusieurs lectures ou plusieurs sous-tâches menées de front, charge d'abord skills/competences/deleguer-a-plusieurs-branches/SKILL.md: elle dit les cinq conditions à réunir, et quand rester ensemble.

Présente un récapitulatif complet:

«Voici l'architecture de votre assistant [Nom de l'agent]:

Rôle: [description en une phrase]

Procédures:

1. [Procédure 1]: [description]

2. [Procédure 2]: [description]

Choix de routage: [chargement manuel de l'agent / routage BASE vers les process / fixtures de routage si besoin]

Connaissances:

1. [Connaissance 1]: [contenu]

2. [Connaissance 2]: [contenu]

3. Communication (règles d'interaction standard)

4. Marqueurs (suivi et traçabilité)

5. Journal (mémoire entre sessions)

Documents:

1. [Template 1]: [sections]

Données:

- [dossier]/: [contenu]

Cette architecture vous convient-elle? Nous pouvons l'ajuster avant que je crée les fichiers.»

⚠ Point de décision, avant création: STOP: ne passe PAS à l'étape 7 tant que l'utilisateur n'a pas dit explicitement qu'il approuve ce plan. Attends un accord clair («oui», «c'est bon», «on y va») avant de créer quoi que ce soit.

7. Créer les fichiers de l'agent

Crée la structure dans .ai/agents/[nom-agent]/:

1. AGENT.md: renseigne l'identité, la philosophie d'interaction (5 points), la doctrine agent → process → ressources, la section «Où router» (un pointeur vers l'index généré: le routage vit dans les frontmatter des SKILL.md, jamais dans une table à la main), les fichiers métier et les garde-fous (6 points, dont le contrôle mécanique, la validation humaine et la séparation instructions/données). Pars de .ai/agents/_template/AGENT.md.

1. skills/processes/: un dossier par process identifié, chaque dossier contient un SKILL.md au format standard avec frontmatter. Si l'utilisateur veut le routage BASE ou si plusieurs process sont proches, ajoute schema_version, id, type: process, description, use_when et, si utile, routing.examples / routing.avoid_when. Rédige `use_when`, `description` et `routing.examples` dans la langue de l'utilisateur (le routage compare les mots de la demande à ceux-ci; en allemand, écris-les en allemand). Deux règles d'hygiène pour ces signaux: écarte les mots outils des routing.examples et des keywords («je voudrais», «est-ce que» se retrouvent partout et ne distinguent rien), et rédige chaque avoid_when avec les mots du cas à exclure, jamais avec ceux du process lui-même, sinon le veto lui retire les demandes qu'il sert (base validate le signale). Distingue reformulations (légères) et points de décision (avant action irréversible). Nomme une à trois preuves observables permettant de conclure: fichier produit, source citée, calcul vérifié, commande réussie ou décision humaine explicite. Chaque process se termine par une étape Journal.

1. skills/competences/: un dossier par domaine de connaissance identifié, chaque dossier contient un SKILL.md avec user-invocable: false. Plus les 3 compétences standard:

• Copie marqueurs/SKILL.md depuis _template/skills/competences/marqueurs/
• Copie journal/SKILL.md depuis _template/skills/competences/journal/
• Copie communication/SKILL.md depuis _template/skills/competences/communication/

1. templates/: un fichier par document type, avec des placeholders en MAJUSCULES

1. tools/ (optionnel): scripts si des besoins d'automatisation ont été identifiés

1. .ai/routing/route-tests.json (si routage BASE activé): quelques demandes réalistes et la route déterministe attendue pour les scripts et intégrations sans modèle. Ces fixtures ne remplacent pas le jugement d'un modèle, qui lit la carte générée et vérifie lui-même le process à suivre.

Pour chaque fichier créé, présente un résumé à l'utilisateur (non le contenu technique, mais ce à quoi il sert).

8. Créer les dossiers métier

À la racine du projet, crée les dossiers identifiés à l'étape 5. Pour chaque dossier, un fichier principal avec des placeholders [A COMPLETER: ...].

9. Configurer l'outil

«Quel outil utilisez-vous? Claude Code, Cursor, Codex, ou autre?»

Selon la réponse:

1. Cherche la documentation à jour de l'outil en ligne (si l'accès web est disponible)
2. À défaut, réfère-toi à skills/competences/outils-connus/SKILL.md
3. Génère les fichiers de configuration de l'outil en mettant en place les 5 primitives:

• Contexte permanent: fichier qui charge AGENT.md au démarrage (ex. CLAUDE.md avec une ligne @.ai/agents/[nom]/AGENT.md)
• Skills découvrables: copier/lier les skills au bon emplacement pour l'outil
• Règles par chemin: garde-fous activés quand l'agent touche des fichiers métier
• Permissions: contrôler ce que l'agent peut faire (si l'outil le supporte)
• Protection du cadre: empêcher la modification directe de .ai/agents/ et .ai/routing/, nommés un par un, le journal (.ai/journal/) restant libre

Avant de configurer, reprends les lignes rouges de l'AGENT.md avec la personne et demande, pour chacune, ce que coûte une seule erreur. Une ligne critique (argent, donnée qui sort, engagement envers un tiers) reçoit un verrou: voir «Garde-fous» dans architecture-agent. Les autres restent des phrases. Présente le tableau: ligne rouge, coût d'une erreur, verrou.

⚠ Point de décision, avant configuration:

«Voici ce que je vais configurer pour [outil]: [description]. Confirmez-vous?»

10. Valider et rafraîchir la carte de routage

Si un terminal est disponible, vérifie le travail avec les mécanismes de BASE plutôt qu'à l'œil: