/create-bot

name: create-bot
description: Use when building a BOT — one place to open a session and work across several Areas or projects at once, with their criteria already loaded, instead of answering questions about them. Scaffolds bots/proyectos/<slug>/ with an always-loaded canon/, its project Lore, and (in `federar` mode) a routing table into Lore scattered across other Areas. Two modes — `nuevo` (canon from a brainstorm plus source docs) and `federar` (canon plus federated routing) — plus an audit pass for a bot that already exists, to fix its scope, README or sources. Scope comes from the registry of the institution the bot serves, never from the builder's folder tree. Sources with NO Lore go through create-area and transmute-lore first, never absorbed into the bot. Packaging as a shareable plugin, encryption and Telegram are optional and off by default. Trigger on "create a bot for X", "a bot that works on <projects>", "federate these areas", "audit my bot", "fix my bot's scope".

create-bot — Build a bot: an installable place to work

Creates a **bot**: a folder that is at once a Claude Code **plugin**, a Lore **project**, and the **place a work session is opened in**. A bot does not answer questions about the projects — it **works in them**. The instruction goes in, the bot executes it against real files, the result comes back.

> **The north, and the only test that matters:** *a short instruction is enough.* If the project > had to be explained to the bot to get the result, criteria were missing from the load.

What a bot is, and what it is not

`create-bot` is a sibling of `create-project`, not of `create-area`. **The standard path is `bots/proyectos/{slug}/`** — `bots` is the area that hosts bots, the way a `web` area hosts websites. If that area does not exist yet, `create-area` makes it first, exactly as for any other project. Another area can host a bot when the user says so; do not assume it.

| | Area | Project | **Bot** | |---|---|---|---| | Holds | projects | one piece of work | **a work session** | | Its Lore governs | the domain's method | that work | **how the agent behaves** | | Opened to | see the registry | advance that work | **work on any of several projects** |

A bot is the only artifact in this kit that **routes outward**. Areas and projects are places; a bot is a lens you carry into them.

> **A bot is not automatically a plugin.** By default it is a folder with its canon and its > `CLAUDE.md`: open a session there and the criteria is already loaded, with nothing installed. > Wrapping it in a skill with `.claude-plugin/` and its own repository is an **optional seal** (§10) > that serves one purpose — handing it to a team. For one person working alone it is scaffolding > that still has to be maintained.

> **Why it must not be an area.** An area is a container of projects and owns the criteria of its > domain. A bot owns none of the criteria it routes to — it borrows it. Building it as an area > creates a parent that accumulates criteria it never paid for, and the first consequence shows up > fast: when a criterion generalizes, it gets promoted to the bot instead of to the area that > earned it.

Two modes

| Mode | When | What it produces | |---|---|---| | **`nuevo`** | From zero. There is no prior Lore to gather. | Canon born from a brainstorm + source documents. | | **`federar`** | The criteria already exists, dissolved across several areas. | Canon **plus** a synchronized copy and a routing table over those Lore bodies. |

Both produce the same artifact. `federar` adds `scripts/ecosistema.json`, `scripts/sync.js`, and two generated files: `lore/enrutamiento.md` (the routing table) and `.claude/settings.local.json` (the access to the live trees). It copies nothing unless the copy is turned on (§7).

When the bot already exists

Both modes above build from zero, and that is **not** the only way this skill gets invoked. It also gets pointed at a bot already in the tree — to fix its scope, rewrite its README, add a source. Run the audit below **instead of** the creation procedure, then rejoin at §7 (sync), §10 (packaging) and §11 (verify).

| Check | How | Fails when | |---|---|---| | **Scope** | Contrast every entry of the manifest against the institution's registry | A source is routed that the registry does not list | | **Borders** | Read the canon's out-of-scope declaration | A borderline project is missing, or is listed with no reason for the confusion | | **Orphans** | `ls` the sync destination against the manifest — only if the copy is on | A folder survives whose source is no longer in the manifest | | **Copy** | Ask who uses the bot and whether they have the tree | `lore-ecosistema/` is on for people who all share the folder tree — it is duplication with no reader | | **README** | Read it as the audience, not as the author | It argues the method, or its examples are about projects the bot no longer serves | | **Install** | Run the commands, do not read them | They were written from memory or copied from a public bot | | **Gate** | `node scripts/validar.js`, if the bot is packaged | Anything but exit 0 |

The audit is not a lighter procedure. It finds what a fresh build cannot: **the drift between what the bot was built to serve and what it serves now**, which is exactly what nobody re-derives on their own.

When a source has no Lore yet

The common starting point is **not** a tidy set of Lore bodies. It is raw material: folders of documents, a codebase, a database, a Notion workspace — none of it distilled. That material cannot be federated, and the fix is a chain, **not** a shortcut:

raw source (no Lore)
   └─ create-area        → the work area that will OWN this criteria
        └─ transmute-lore (add)  → recover the criteria already scattered inside it
             └─ create-bot (federar)  → the bot routes to it

> **The law: the bot never distills into itself.** A source without Lore gets its Lore **in the area > that own