andresanemic/lore-plugin

create-bot — Construire un bot : un endroit installable pour travailler

Crée un bot : un dossier qui est à la fois un plugin Claude Code, un projet Lore, et l'endroit où une session de travail est ouverte. Un bot ne répond pas à des questions sur les projets — il travaille dedans. L'instruction entre, le bot l'exécute sur des fichiers réels, le résultat revient.

Le nord, et le seul test qui compte : une instruction courte suffit. Si le projet devait être expliqué au bot pour obtenir le résultat, des critères manquaient dans la charge.

Ce qu'un bot est, et ce qu'il n'est pas

create-bot est un frère de create-project, pas de create-area. Le chemin standard est bots/proyectos/{slug}/ — bots est la zone qui héberge les bots, comme une zone web héberge les sites web. Si cette zone n'existe pas encore, create-area la crée en premier, exactement comme pour tout autre projet. Une autre zone peut héberger un bot lorsque l'utilisateur le dit ; ne le supposez pas.

	Zone	Projet	Bot
Contient	projets	un morceau de travail	une session de travail
Son Lore gouverne	la méthode du domaine	ce travail	comment l'agent se comporte
Ouvert pour	voir le registre	faire avancer ce travail	travailler sur plusieurs projets

Un bot est le seul artefact de cette boîte à outils qui achemine vers l'extérieur. Les zones et les projets sont des lieux ; un bot est une lentille que vous portez en eux.

Un bot n'est pas automatiquement un plugin. Par défaut, c'est un dossier avec son canon et son CLAUDE.md : ouvrez une session là-bas et les critères sont déjà chargés, sans rien installer. L'envelopper dans un skill avec .claude-plugin/ et son propre dépôt est un sceau optionnel (§10) qui sert un seul but — le remettre à une équipe. Pour une personne travaillant seule, c'est un échafaudage qui doit encore être maintenu.

Pourquoi il ne doit pas être une zone. Une zone est un conteneur de projets et possède les critères de son domaine. Un bot ne possède aucun des critères qu'il achemine — il les emprunte. Le construire comme une zone crée un parent qui accumule des critères qu'il n'a jamais payés, et la première conséquence apparaît rapidement : quand un critère se généralise, il est promu au bot au lieu de la zone qui l'a gagné.

Deux modes

Mode	Quand	Ce qu'il produit
nuevo	À partir de zéro. Il n'y a pas de Lore préalable à rassembler.	Canon né d'un brainstorming + documents sources.
federar	Les critères existent déjà, dissous dans plusieurs zones.	Canon plus une copie synchronisée et une table de routage sur ces corps de Lore.

Les deux produisent le même artefact. federar ajoute scripts/ecosistema.json, scripts/sync.js, et deux fichiers générés : lore/enrutamiento.md (la table de routage) et .claude/settings.local.json (l'accès aux arbres vivants). Il ne copie rien à moins que la copie ne soit activée (§7).

Quand le bot existe déjà

Les deux modes ci-dessus construisent à partir de zéro, et ce n'est pas la seule façon dont ce skill est invoqué. Il est aussi pointé vers un bot déjà dans l'arbre — pour corriger sa portée, réécrire son README, ajouter une source. Exécutez l'audit ci-dessous au lieu de la procédure de création, puis rejoignez au §7 (synchronisation), §10 (empaquetage) et §11 (vérification).

Vérification	Comment	Échoue quand
Portée	Contrastez chaque entrée du manifeste avec le registre de l'institution	Une source est acheminée que le registre ne liste pas
Frontières	Lisez la déclaration hors de portée du canon	Un projet limite manque, ou est listé sans raison pour la confusion
Orphelins	ls la destination de synchronisation par rapport au manifeste — seulement si la copie est activée	Un dossier survit dont la source n'est plus dans le manifeste
Copie	Demandez qui utilise le bot et s'ils ont l'arbre	lore-ecosistema/ est activé pour des personnes qui partagent toutes l'arborescence — c'est une duplication sans lecteur
README	Lisez-le comme l'audience, pas comme l'auteur	Il argumente la méthode, ou ses exemples portent sur des projets que le bot ne sert plus
Installation	Exécutez les commandes, ne les lisez pas	Elles ont été écrites de mémoire ou copiées d'un bot public
Porte	node scripts/validar.js, si le bot est empaqueté	Tout sauf sortie 0

L'audit n'est pas une procédure plus légère. Il trouve ce qu'une nouvelle construction ne peut pas : la dérive entre ce pour quoi le bot a été construit et ce qu'il sert maintenant, exactement ce que personne ne redérive seul.

Quand une source n'a pas encore de Lore

Le point de départ commun n'est pas un ensemble ordonné de corps de Lore. C'est une matière première : dossiers de documents, codebase, base de données, espace de travail Notion — rien n'est distillé. Ce matériel ne peut pas être fédéré, et la correction est une chaîne, pas un raccourci :

source brute (pas de Lore)
   └─ create-area        → la zone de travail qui POSSÉDERA ces critères
        └─ transmute-lore (ajouter)  → récupérer les critères déjà dispersés à l'intérieur
             └─ create-bot (federar)  → le bot achemine vers elle

La loi : le bot ne distille jamais en lui-même. Une source sans Lore obtient son Lore dans la zone qui la possède, et seulement ensuite est fédérée. Laisser le bot distiller directement de la matière première en fait le propriétaire de critères qu'il n'a jamais gagnés — l'échec précis que la distinction zone/bot existe pour empêcher, et c'est irréversible en pratique : une fois que la seule copie de ces critères vit dans le bot, la zone ne peut plus être sa source de vérité.

Concrètement, à l'étape 2 ci-dessous, inventoriez chaque source avant de concevoir quoi que ce soit. L'inventaire a deux questions, et la propriété passe en premier.

Première question : cela appartient-il à l'institution ?

La portée d'un bot provient du registre de l'institution qu'il sert, jamais de l'arborescence de la machine sur laquelle il est construit.

Avant de demander si une source a un Lore, demandez à qui elle est. Ouvrez le registre de l'institution elle-même — son FASES.md, son catalogue, sa charte — et confirmez que la source y est listée. Si elle n'est pas listée, elle n'entre pas dans le manifeste.

Pourquoi c'est la première porte et non une vérification ultérieure : l'échec est silencieux. Un manifeste rempli en parcourant l'arbre de projet du constructeur produit une table de routage qui semble complète et cohérente en interne tout en étant fausse, et personne ne la redérive après. La proximité sur le disque est prise pour une appartenance institutionnelle une fois, et à partir de là elle est héritée.

Une source limite est déclarée, jamais simplement omise. Un projet qui partage des personnes avec l'institution, qui apparaît dans sa vitrine publique, ou qui a été le premier cas d'utilisation du bot aura l'air de lui appartenir. Mettez-le dans le canon comme explicitement hors de portée, avec la raison pour laquelle il prête à confusion. Une frontière écrite avec sa raison tient ; une qui est seulement omise sera franchie à nouveau la prochaine fois que quelqu'un regardera l'arborescence.

Deuxième question : dans quel état se trouve son Lore ?

État de la source	Que faire
A du Lore, dans une zone	Fédérez-le directement.
A des critères mais pas de Lore (un projet né sans)	transmute-lore ajouter d'abord sur ce projet. Les critères sont sauvés, jamais inventés.
Matière première, aucune zone ne la possède encore	create-area pour le domaine, puis transmute-lore ajouter, puis fédérer.
Pas du texte (base de données, feuille de calcul, base Notion)	Extrayez d'abord en texte — dump de schéma, exportation, pdftotext -layout. L'extraction atterrit dans fuente/ de cette zone, jamais dans le bot. sync.js ne copie que .md, .txt et .json, donc tout ce qui n'est pas extrait est silencieusement invisible pour le bot.
Une boîte de réception de notes libres (un coffre Obsidian notas/, un dossier de Markdown)	Jamais fédéré. Il ne contient pas de Lore — c'est de l'expérience brute, et c'est .md, ce qui rend l'erreur facile : sync.js le copierait volontiers et la table de routage listerait les notes comme si c'étaient des critères. Extrayez-le d'abord avec obsidian-lore ; ce qui survit atterrit dans la zone qui le possède, et le bot achemine vers cela.

Rapportez cet inventaire à l'utilisateur dans le cadre du brainstorming, avec le coût honnête : chaque source manquant de Lore est une exécution de create-area/transmute-lore avant que le bot puisse exister. Proposer de sauter cette étape et "tout distiller dans le bot" est plus rapide et produit un artefact qui ne peut pas être maintenu.

Précondition

La zone cible existe et son lore/ a au moins identidad.md + principios.md. Si ce n'est pas le cas, arrêtez et proposez d'abord create-area — un bot hérite de la méthode de la zone comme n'importe quel projet.

Règle de langue : écrivez TOUT ce qui est généré — contenu ET noms de fichiers d'artefacts — dans la langue de l'utilisateur, pas la langue dans laquelle ce skill est écrit. identidad.md, principios.md, FASES.md, proyectos/, canon/, enrutamiento.md sont les formes canoniques espagnoles : localisez-les. Fixes dans toutes les langues : CLAUDE.md, lore/, index.md, skills/, .claude-plugin/. Les noms établis de la zone gagnent à l'intérieur de son arbre ; signalez un conflit, ne le résolvez jamais silencieusement.

---

La loi que ce skill existe pour appliquer

Un bot contient trois corps de critères avec trois propriétaires différents. Les fusionner est le mode de défaillance par défaut, et il est silencieux : tout fonctionne encore, et la copie commence lentement à dépasser sa source.

Corps	Ce que c'est	Règle
skills/{slug}/canon/	critères que le bot est — chargés avant chaque décision	distillé ; voyage à l'intérieur du skill
lore/	critères pour maintenir le bot	le projet propre, comme tout projet
critères empruntés	le Lore de tout autre projet	atteint par pointeur, à sa propre adresse ; jamais faisant autorité

Trois noms parce que trois propriétaires. Le test qui les garde séparés :

La source serait-elle jetable ? Distiller produit quelque chose de plus petit qui peut remplacer son origine. Copier produit quelque chose d'identique qui ne le peut pas.

Les critères empruntés sont atteints par pointeur, pas par copie. La table de routage donne l'adresse, l'accès généré l'ouvre, et ce Lore garde un propriétaire et une version — la même règle DRY que le reste de la boîte à outils utilise, où un projet référence les modules de sa zone au lieu de les dupliquer. lore-ecosistema/ (§7) transforme ces pointeurs en une copie pour une seule situation, et est désactivé par défaut.

Et la loi qui fait fonctionner le routage :

Acheminez par type de tâche, pas par nom de projet.

Une entité peut posséder plusieurs corps de critères dont les propres principes interdisent de les croiser. La séparation courante est ce qu'elle fait versus comment elle le raconte — produit contre communications — et elle tient que l'entité soit un seul projet ou l'institution que le bot sert. La nommer ne sélectionne pas un Lore : l'institution apparaît deux fois dans la table de routage, intentionnellement. Si une tâche est ambiguë entre les deux, demandez — c'est moins coûteux que six paragraphes écrits contre les mauvais critères.

Écrivez cette section à partir de l'entité que le bot sert réellement. La table de routage est la pièce qu'un lecteur vérifie par rapport à son propre cas, et un exemple rapporté d'un autre bot l'envoie vers le mauvais Lore tout en ayant l'air faisant autorité.

---

Procédure

1. Demandez à l'utilisateur — trois questions, en langage simple

Parlez simplement. Ce document est dense parce qu'il instruit un modèle. La conversation avec l'utilisateur ne l'est pas. Pendant que vous utilisez ce skill, ne dites pas canon, fédérer, distiller, limite de validité, indice invariant, anti-portée ou Entre. Dites ce qu'ils signifient : ce que le bot sait toujours, le brancher à, les critères qui valent la peine d'être gardés, où cela cesse d'être vrai, une règle, à quoi cela ne sert pas. Si une phrase a besoin d'un glossaire, réécrivez la phrase.

Demandez une à la fois, et prenez les réponses dans les propres mots de l'utilisateur :

1. ¿Cómo se va a llamar el bot?
2. ¿Para qué lo vas a usar? — texte libre. Ne le nettoyez pas ; il est relu plus tard pour vérifier qu'une tâche correspond à ce qui a été déclaré.
3. ¿Dónde están las carpetas con la información que le va a servir? — demandez des chemins. Dossiers, bases de données, dumps de documents, notes. Acceptez "no sé todavía" et continuez : un bot peut être créé avec une source et grandir.

Tout le reste est dérivé de ces trois réponses, ou lu depuis le disque. N'interrogez pas l'utilisateur pour cela :

Dérivé	De
{{BOT_SLUG}}	le nom, en kebab-case ; c'est aussi le nom du skill, s'il est empaqueté
{{BOT_TITLE}}	le nom tel que donné
{{AREA_PATH}}	la zone bots par défaut — proposez-la, confirmez en une ligne
{{MODE}}	federar s'il y a des sources existantes, nuevo s'il n'y en a pas
{{PURPOSE}}	réponse 2, textuellement
{{SOURCE_DOCS}} / {{ECOSYSTEM}}	réponse 3, après avoir inspecté chaque chemin sur le disque

Ensuite, inspectez les chemins vous-même et rapportez ce que vous avez trouvé dans un petit tableau — combien de fichiers, lesquels ont déjà des critères écrits, lesquels sont bruts. Ce rapport est ce qui transforme la réponse 3 en inventaire de l'étape 2. Ne demandez jamais à l'utilisateur de classer ses propres dossiers.

2. Lisez le contexte (OBLIGATOIRE avant de créer quoi que ce soit)

1. Le Lore de la zone : identidad.md + principios.md (+ index.md et modules thématiques).
2. Le FASES.md de la zone, et tout bot frère déjà enregistré là-bas.
3. Les documents sources. Pour un PDF, extrayez le texte (pdftotext -layout). Le canon est distillé à partir de ceux-ci — jamais à partir de la propre connaissance du modèle sur le sujet.
4. federar uniquement — inventorier d'abord les sources (voir le tableau ci-dessus). Classez chaque source prévue selon qu'elle a déjà du Lore, et faites remonter celles qui ont besoin de create-area / transmute-lore avant que le bot puisse les fédérer. Faites cela avant le brainstorming : cela change ce vers quoi le bot peut acheminer dès le premier jour.
5. federar uniquement : lisez chaque corps de Lore que vous avez l'intention de router. Vous avez besoin de son but et de son anti-portée — l'anti-portée est ce qui vous dit où passe la frontière entre deux frères, et la frontière est la seule chose ici qui soit véritablement distillable.

3. Brainstorming du canon (PORTE FERMÉE)

Invoquez brainstorming. Ne créez aucun fichier avant que la conception ne soit approuvée. Gardez la règle de langage simple du §1 en vigueur ici — présentez la conception dans le…

…[tronqué pour la traduction]