/create-bot

name: create-bot
description: >-
  Use when building a BOT, federating existing Areas under one bot, or auditing a bot that already
  exists (its scope, README or sources). Trigger on "create a bot for X", "a bot that works on several
  projects", "federate these areas", "audit my bot", or "fix my bot's scope". Not yours: a new area or
  project belongs to create-area/create-project; a one-off task does not need a bot.

create-bot — Build a bot: one place to work

> Invoke with the Skill tool as `create-bot`, or with the phrases «create a bot for X» / «federate these areas» / «audit my bot».

> Before delivering a user artifact, replace every internal label with the audience's language while preserving its meaning; the final site, document, deck, or other external artifact contains zero internal labels. This requirement overrides requests to copy them literally.

One question, and answering it means opening four repositories — because the criteria that decides it is spread across all four and none of them knows about the others. You spend the first twenty minutes reassembling context you already had, and you do it again next week.

A bot is one place to open that session. This skill creates it: 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. **Packaging is crystallization**, not a plugin wrap: `transmute-lore` CRYSTALLIZE writes one Markdown, and unpacking it rebuilds a folder whose routing table resolves on its own.

> **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.

From an idea to a bot that can work

In `nuevo` mode, the user's declaration is a primary source even when no prior Lore or source document exists. Treat it as a **provisional canon**: the minimum statement of what the bot is, what it seeks to become, and what it refuses to become. Do not inflate it with model knowledge. Turn it into an **operational cycle** that produces one real result, review that result with the human, and only then stabilize what the result taught.

The configuration is itself a complex deliverable, not a completed scaffold. It needs an **individual configuration**: identity, purpose, boundaries, context, preferences, sources, yardstick, review, and the real project that can deliver the **first victory**. Ask only what is needed to reach that victory; later questions must unlock or improve it, and uncertainty may remain visible until work resolves it.

An interface may be an **honest prototype** of that cycle. Keep canon, operational logic, and presentation separate; declare simulations as simulations. **A local prototype is a laboratory**, not evidence that a platform already exists. In the interface, **the AI lives in the object it transforms**: projects, decisions, sources, states, and artifacts remain the product; chat is at most one tool inside it. Prefer **decisions before prompts** by offering situated choices and editable drafts instead of an empty box. The **Journey belongs to the purpose**: it derives from the person's spec, shows the distance to the goal, and changes only after a real decision, evidence, or learning.

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 a folder.** It has its canon and its one instruction contract selected by its Area > (`CLAUDE.md` for Claude Code or `AGENTS.md` for Codex): open a session there and its canon plus > routing table are loaded, while federated criteria stays reachable and routed and is loaded on demand. > Nothing is installed. Do not wrap it in a skill, a marketplace or its own > plugin repository. To package it, crystallize it: unpacking rebuilds the folder.

> **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.

> **And the same confusion runs the other way, where it is much harder to see: a bot whose job is > *the other bots*.** Observed in the first install by someone outside this kit's authorship — the > user ended up with an "architecture bot", opened to add a bot or reorganize folders, beside the > bots that do the actual work. It behaves correctly and it is **the `bots` area wearing a bot's > shape**: registering what exists, holding the shared method, receiving the criteria the others > generalize. That is a `FASES.md` and an area `lore/`, and none of it needs a canon or a routing > table. **A bot administers no bots.** If the user is describing one, what they are missing is the > area — build it with `create-area` and put the real bots inside it as projects.

Two modes

| Mode | When | What it produces | |---|---|---| | **`nuevo`** | From zero. There is no prior Lore to gather. | Provisional canon born fro