create-bot — Construye un bot: un lugar instalable para trabajar
Crea un bot: una carpeta que es a la vez un plugin de Claude Code, un proyecto de Lore y el lugar donde se abre una sesión de trabajo. Un bot no responde preguntas sobre los proyectos — trabaja en ellos. La instrucción entra, el bot la ejecuta contra archivos reales, el resultado vuelve.
El norte, y la única prueba que importa: una instrucción corta es suficiente. Si el proyecto tuvo que explicarse al bot para obtener el resultado, faltaban criterios en la carga.
Qué es un bot, y qué no es
create-bot es hermano de create-project, no de create-area. La ruta estándar es bots/proyectos/{slug}/ — bots es el área que alberga bots, igual que un área web alberga sitios web. Si esa área aún no existe, create-area la crea primero, exactamente como para cualquier otro proyecto. Otra área puede albergar un bot cuando el usuario lo indique; no lo asumas.
| Área | Proyecto | Bot | |
|---|---|---|---|
| Contiene | proyectos | una pieza de trabajo | una sesión de trabajo |
| Su Lore rige | el método del dominio | ese trabajo | cómo se comporta el agente |
| Se abre para | ver el registro | avanzar ese trabajo | trabajar en varios proyectos |
Un bot es el único artefacto de este kit que enruta hacia afuera. Las áreas y proyectos son lugares; un bot es una lente que llevas dentro de ellos.
Un bot no es automáticamente un plugin. Por defecto es una carpeta con su canon y su
CLAUDE.md: abre una sesión allí y el criterio ya está cargado, sin nada instalado. Envolverlo en un skill con.claude-plugin/y su propio repositorio es un sello opcional (§10) que sirve para un solo propósito: entregarlo a un equipo. Para una persona que trabaja sola, es andamio que aún hay que mantener.
Por qué no debe ser un área. Un área es un contenedor de proyectos y es dueña del criterio de su dominio. Un bot no es dueño de ningún criterio al que enruta — lo toma prestado. Construirlo como área crea un padre que acumula criterio que nunca pagó, y la primera consecuencia aparece rápido: cuando un criterio se generaliza, se promueve al bot en lugar del área que lo ganó.
Dos modos
| Modo | Cuándo | Qué produce |
|---|---|---|
nuevo | Desde cero. No hay Lore previo que recolectar. | Canon nacido de una lluvia de ideas + documentos fuente. |
federar | El criterio ya existe, disuelto en varias áreas. | Canon más una copia sincronizada y una tabla de enrutamiento sobre esos cuerpos de Lore. |
Ambos producen el mismo artefacto. federar añade scripts/ecosistema.json, scripts/sync.js y dos archivos generados: lore/enrutamiento.md (la tabla de enrutamiento) y .claude/settings.local.json (el acceso a los árboles vivos). No copia nada a menos que la copia esté activada (§7).
Cuando el bot ya existe
Ambos modos anteriores construyen desde cero, y esa no es la única forma en que se invoca este skill. También se apunta a un bot ya existente en el árbol — para arreglar su alcance, reescribir su README, añadir una fuente. Ejecuta la auditoría siguiente en lugar de el procedimiento de creación, luego reincorpórate en §7 (sincronización), §10 (empaquetado) y §11 (verificación).
| Verificación | Cómo | Fallo cuando |
|---|---|---|
| Alcance | Contrasta cada entrada del manifiesto contra el registro de la institución | Una fuente está enrutada que el registro no lista |
| Límites | Lee la declaración de fuera de alcance del canon | Falta un proyecto fronterizo, o está listado sin razón para la confusión |
| Huérfanos | ls al destino de sincronización contra el manifiesto — solo si la copia está activada | Sobrevive una carpeta cuya fuente ya no está en el manifiesto |
| Copia | Pregunta quién usa el bot y si tienen el árbol | lore-ecosistema/ está activado para personas que comparten el árbol de carpetas — es duplicación sin lector |
| README | Léele como el público, no como el autor | Argumenta el método, o sus ejemplos tratan sobre proyectos que el bot ya no sirve |
| Instalación | Ejecuta los comandos, no los leas | Fueron escritos de memoria o copiados de un bot público |
| Puerta | node scripts/validar.js, si el bot está empaquetado | Cualquier cosa que no sea salir con código 0 |
La auditoría no es un procedimiento más ligero. Encuentra lo que una construcción fresca no puede: la deriva entre lo que el bot fue construido para servir y lo que sirve ahora, que es exactamente lo que nadie vuelve a derivar por su cuenta.
Cuando una fuente aún no tiene Lore
El punto de partida común no es un conjunto ordenado de cuerpos de Lore. Es material en bruto: carpetas de documentos, un código base, una base de datos, un espacio de Notion — nada destilado. Ese material no puede federarse, y la solución es una cadena, no un atajo:
fuente en bruto (sin Lore)
└─ create-area → el área de trabajo que será DUEÑA de este criterio
└─ transmute-lore (añadir) → recupera el criterio ya disperso dentro de ella
└─ create-bot (federar) → el bot enruta hacia ella
La ley: el bot nunca destila dentro de sí mismo. Una fuente sin Lore obtiene su Lore en el área que es dueña de ella, y solo entonces se federada. Dejar que el bot destile material en bruto directamente lo convierte en el dueño de criterio que nunca ganó — el fallo preciso que la distinción área/bot existe para prevenir, y es irreversible en la práctica: una vez que la única copia de ese criterio vive en el bot, el área ya no puede ser su fuente de verdad.
Concretamente, en el paso 2 a continuación, inventaria cada fuente antes de diseñar nada. El inventario tiene dos preguntas, y la propiedad viene primero.
Primera pregunta: ¿esto pertenece a la institución?
El alcance de un bot proviene del registro de la institución a la que sirve, nunca del árbol de carpetas de la máquina en la que se está construyendo.
Antes de preguntar si una fuente tiene Lore, pregunta de quién es. Abre el registro de la propia institución — su FASES.md, su catálogo, su carta fundacional — y confirma que la fuente está listada allí. Si no está listada, no entra en el manifiesto.
Por qué esta es la primera puerta y no una verificación posterior: el fallo es silencioso. Un manifiesto llenado recorriendo el árbol de proyectos del constructor produce una tabla de enrutamiento que parece completa e internamente consistente mientras está equivocada, y nadie la vuelve a derivar después. La proximidad en el disco se confunde con membresía institucional una vez, y de ahí en adelante se hereda.
Una fuente fronteriza se declara, nunca se omite meramente. Un proyecto que comparte personas con la institución, que aparece en su escaparate público, o que fue el propio caso de uso inicial del bot, parecerá que pertenece. Ponlo en el canon como explícitamente fuera de alcance, con la razón por la que se confunde. Un límite escrito con su razón se sostiene; uno que solo se omite se cruza de nuevo la próxima vez que alguien mira el árbol de carpetas.
Segunda pregunta: ¿en qué estado está su Lore?
| Estado de la fuente | Qué hacer |
|---|---|
| Tiene Lore, en un área | Federarla directamente. |
| Tiene criterio pero no Lore (un proyecto nacido sin él) | transmute-lore añadir en ese proyecto primero. El criterio se rescata, nunca se inventa. |
| Material en bruto, ninguna área es dueña aún | create-area para el dominio, luego transmute-lore añadir, luego federar. |
| No es texto (una base de datos, una hoja de cálculo, una base de Notion) | Extraer a texto primero — volcado de esquema, exportación, pdftotext -layout. La extracción aterriza en el fuente/ de esa área, nunca en el bot. sync.js solo copia .md, .txt y .json, así que cualquier cosa no extraída es silenciosamente invisible para el bot. |
Una bandeja de notas libres (un vault de Obsidian notas/, una carpeta de Markdown) | Nunca federada. No contiene Lore — es experiencia en bruto, y es .md, que es exactamente lo que hace fácil el error: sync.js la copiaría felizmente y la tabla de enrutamiento listaría notas como si fueran criterio. Explótala con obsidian-lore primero; lo que sobrevive aterriza en el área que es dueña de él, y el bot enruta hacia eso. |
Reporta este inventario al usuario como parte de la lluvia de ideas, con el costo honesto: cada fuente que carece de Lore es una ejecución de create-area/transmute-lore antes de que el bot pueda existir. Proponer saltarlo y "destilarlo todo en el bot" es más rápido y produce un artefacto que no se puede mantener.
Precondición
El área de destino existe y su lore/ tiene al menos identidad.md + principios.md. Si no es así, detente y propón create-area primero — un bot hereda el método del área como cualquier proyecto.
Regla de idioma: escribe TODO lo generado — contenido Y nombres de archivos del artefacto — en el idioma del usuario, no en el idioma en que está escrito este skill.
identidad.md,principios.md,FASES.md,proyectos/,canon/,enrutamiento.mdson las formas canónicas en español: localízalas. Fijos en todos los idiomas:CLAUDE.md,lore/,index.md,skills/,.claude-plugin/. Los nombres establecidos del área ganan dentro de su árbol; señala un conflicto, nunca lo resuelvas en silencio.
La ley que este skill existe para hacer cumplir
Un bot contiene tres cuerpos de criterio con tres dueños diferentes. Fusionarlos es el modo de fallo por defecto, y es silencioso: todo sigue funcionando, y la copia lentamente comienza a superar a su fuente.
| Cuerpo | Qué es | Regla |
|---|---|---|
skills/{slug}/canon/ | criterio que el bot es — cargado antes de cada decisión | destilado; viaja dentro del skill |
lore/ | criterio para mantener el bot | el propio del proyecto, como cualquier proyecto |
| criterio prestado | el Lore de todos los demás proyectos | alcanzado por puntero, en su propia dirección; nunca autoritativo |
Tres nombres porque tres dueños. La prueba que los mantiene separados:
¿Sería descartable la fuente? Destilar produce algo más pequeño que puede reemplazar su origen. Copiar produce algo idéntico que no puede.
El criterio prestado se alcanza por puntero, no por copia. La tabla de enrutamiento da la dirección, el acceso generado la abre, y ese Lore mantiene un dueño y una versión — la misma regla DRY que ejecuta el resto del kit, donde un proyecto referencia los módulos de su área en lugar de duplicarlos. lore-ecosistema/ (§7) convierte esos punteros en una copia para una sola situación, y está desactivado por defecto.
Y la ley que hace que el enrutamiento funcione:
Enruta por tipo de tarea, no por nombre de proyecto.
Una entidad puede ser dueña de varios cuerpos de criterio cuyos propios principios prohíben cruzarlos. La división común es lo que hace versus cómo lo cuenta — producto contra comunicaciones — y se sostiene tanto si la entidad es un solo proyecto como si es la institución a la que sirve el bot. Nombrarlo no selecciona un Lore: la institución aparece dos veces en la tabla de enrutamiento, a propósito. Si una tarea es ambigua entre dos, pregunta — es más barato que seis párrafos escritos contra el criterio equivocado.
Escribe esta sección desde la entidad a la que el bot realmente sirve. La tabla de enrutamiento es la pieza que un lector verifica contra su propio caso, y un ejemplo traído de otro bot los envía al Lore equivocado mientras parece autoritativo.
Procedimiento
1. Pregunta al usuario — tres preguntas, en lenguaje llano
Habla con claridad. Este documento es denso porque instruye a un modelo. La conversación con el usuario no lo es. Mientras uses este skill, no digas canon, federar, destilar, límite de validez, pista invariante, anti-álcance ni Entre. Di lo que significan: lo que el bot siempre sabe, conectarlo a, el criterio que vale la pena conservar, dónde esto deja de ser cierto, una regla, para qué no sirve. Si una frase necesita un glosario, reescribe la frase.
Pregunta una a la vez, y toma las respuestas en las propias palabras del usuario:
- ¿Cómo se va a llamar el bot?
- ¿Para qué lo vas a usar? — texto libre. No lo ordenes; se relee después para verificar que una tarea coincida con lo declarado.
- ¿Dónde están las carpetas con la información que le va a servir? — pide rutas. Carpetas, bases de datos, volcados de documentos, notas. Acepta "no sé todavía" y continúa: un bot puede crearse con una fuente y crecer.
Todo lo demás se deriva de esas tres, o se lee del disco. No interrogues al usuario por ello:
| Derivado | De |
|---|---|
{{BOT_SLUG}} | el nombre, en kebab-case; este es también el nombre del skill, si está empaquetado |
{{BOT_TITLE}} | el nombre tal como se dio |
{{AREA_PATH}} | el área bots por defecto — proponla, confirma en una línea |
{{MODE}} | federar si hay fuentes existentes, nuevo si no hay ninguna |
{{PURPOSE}} | respuesta 2, textual |
{{SOURCE_DOCS}} / {{ECOSYSTEM}} | respuesta 3, después de inspeccionar cada ruta en el disco |
Luego inspecciona las rutas tú mismo e informa lo que encontraste en una tabla corta — cuántos archivos, cuáles ya tienen criterio escrito, cuáles están en bruto. Ese informe es lo que convierte la respuesta 3 en el inventario del paso 2. Nunca le pidas al usuario que clasifique sus propias carpetas.
2. Lee el contexto (OBLIGATORIO antes de crear nada)
- El Lore del área:
identidad.md+principios.md(+index.mdy módulos temáticos). - El
FASES.mddel área, y cualquier bot hermano ya registrado allí. - Los documentos fuente. Para un PDF, extrae texto (
pdftotext -layout). El canon se destila de estos — nunca del conocimiento propio del modelo sobre el tema. - Solo
federar— inventaria las fuentes primero (ver la tabla anterior). Clasifica cada fuente prevista por si ya tiene Lore, y saca a relucir las que necesitancreate-area/transmute-loreantes de que el bot pueda federarlas. Haz esto antes de la lluvia de ideas: cambia lo que el bot puede enrutar desde el primer día. - Solo
federar: lee cada cuerpo de Lore al que planeas enrutar. Necesitas su propósito y su anti-álcance — el anti-álcance es lo que te dice dónde corre el límite entre dos hermanos, y el límite es lo único aquí que es genuinamente destilable.
3. Lluvia de ideas del canon (COMPUERTA FUERTE)
Invoca brainstorming. No crees ningún archivo antes de que el diseño esté aprobado. Mantén la regla de lenguaje llano de §1 vigente aquí — presenta el diseño en las
... [truncado para traducción]