create-bot — 构建一个机器人：一个可安装的工作场所
创建一个机器人：一个既是Claude Code插件、又是Lore项目、同时也是工作会话打开位置的文件夹。机器人不回答关于项目的问题——它在这些项目中工作。指令输入，机器人针对真实文件执行，结果返回。
北极星，也是唯一重要的测试： 一个简短的指令就足够了。 如果为了获得结果而必须向机器人解释项目，那么加载时就缺少了标准。
机器人是什么，以及不是什么
create-bot 是 create-project 的同行，而不是 create-area 的同行。标准路径是 bots/proyectos/{slug}/ —— bots 是托管机器人的领域，就像 web 领域托管网站一样。如果该领域尚不存在，create-area 会首先创建它，就像创建任何其他项目一样。当用户要求时，另一个领域也可以托管机器人；不要假定它。
| 领域 | 项目 | 机器人 | |
|---|---|---|---|
| 存储 | 项目 | 一项工作 | 一个工作会话 |
| 其Lore治理 | 领域的方法 | 该工作 | 代理如何表现 |
| 打开以 | 查看注册表 | 推进该工作 | 在多个项目中的任何一个上工作 |
机器人是该工具包中唯一向外路由的人工制品。领域和项目是场所；机器人是你带入其中的一个镜头。
机器人自动不是插件。 默认情况下，它是一个包含其正典和
CLAUDE.md的文件夹：在那里打开一个会话，标准已加载，无需安装任何东西。使用.claude-plugin/和自己的仓库将其包装成一个技能是一个可选封印（§10），其唯一目的是——将其交给团队。对于独自工作的个人来说，它是仍需维护的脚手架。
为什么它不能成为一个领域。 领域是项目的容器，拥有其领域的标准。机器人不拥有它路由到的任何标准——它借用标准。将其构建为领域会创建一个累积其从未支付过的标准的父级，并且第一个后果会很快显现：当一个标准泛化时，它会被提升到机器人，而不是到赢得它的领域。
两种模式
| 模式 | 何时使用 | 产生什么 |
|---|---|---|
nuevo | 从零开始。没有需要收集的先前的Lore。 | 从头脑风暴 + 源文档中诞生的正典。 |
federar | 标准已存在，分散在多个领域中。 | 正典加上一个同步副本和这些Lore主体上的路由表。 |
两者产生相同的人工制品。federar 添加了 scripts/ecosistema.json、scripts/sync.js 和两个生成文件：lore/enrutamiento.md（路由表）和 .claude/settings.local.json（对实时树的访问）。除非开启复制（§7），否则它不会复制任何内容。
当机器人已存在时
以上两种模式都是从零开始构建，但这不是调用此技能的唯一方式。它也可以指向树中已有的机器人——以修正其范围、重写其README、添加来源。代替创建过程运行以下审计，然后重新加入 §7（同步）、§10（打包）和 §11（验证）。
| 检查项 | 方法 | 失败条件 |
|---|---|---|
| 范围 | 将清单中的每个条目与机构的注册表对比 | 路由了一个注册表中未列出的来源 |
| 边界 | 阅读正典的范围外声明 | 缺少边界项目，或列出了但没有混淆的原因 |
| 孤儿 | ls 同步目标并与清单对比——仅当复制开启时 | 存在一个文件夹，其来源不再在清单中 |
| 复制 | 询问谁使用该机器人以及他们是否拥有该树 | 对共享文件夹树的所有人开启 lore-ecosistema/——对于没有读者的用户来说这是重复 |
| README | 以受众身份阅读，而不是作者 | 它争论方法，或者其示例是关于机器人不再服务的项目 |
| 安装 | 运行命令，而不是阅读它们 | 它们是从记忆或从公共机器人复制而来的 |
| 门控 | node scripts/validar.js，如果机器人已打包 | 除了退出码0之外的任何情况 |
审计不是更轻松的程序。它找到了全新构建无法找到的东西：机器人在构建时服务的内容与现在服务的内容之间的漂移，这正是没有人会自行重新推导的内容。
当来源还没有Lore时
常见的起点不是一组整洁的Lore主体。而是原始材料：文档文件夹、代码库、数据库、Notion工作区——没有经过提炼。这种材料无法被联合，修复是一个链条，而不是捷径：
原始来源（无Lore）
└─ create-area → 将拥有此标准的工作领域
└─ transmute-lore (add) → 恢复已经分散在其中的标准
└─ create-bot (federar) → 机器人路由到它
法则：机器人永远不会将内容提炼到自身。 没有Lore的来源会在拥有它的领域中获得其Lore，然后才被联合。让机器人直接提炼原始材料会使其成为它从未赢得的准则的所有者——这正是领域/机器人区分旨在防止的确切失败，并且在实践中是不可逆的：一旦该准则的唯一副本存在于机器人中，该领域就不再能作为其真实来源。
具体来说，在下面的步骤2中，在设计任何事情之前盘点每个来源。盘点有两个问题，并且所有权优先。
第一个问题：这属于该机构吗？
机器人的范围来自其服务的机构的注册表，永远不是来自其构建所在的机器的文件夹树。
在询问来源是否有Lore之前，先问它是谁的。打开机构自己的注册表——它的 FASES.md、它的目录、它的章程——并确认该来源在其上列出。如果未列出，则它不会进入清单。
为什么这是第一个门控而不是稍后的检查： 失败是无声的。通过遍历构建者的项目树填写的清单会产生一个看起来完整且内部一致但错误的的路由表，并且之后没有人会重新推导它。磁盘上的接近性被误认为是机构成员身份一次，然后就被继承下来。
边界来源是被声明的，而不仅仅是省略的。 一个与机构共享人员的项目，一个出现在其公共展示中的项目，或者机器人自己的第一个用例，看起来会像它属于这里。将其放入正典中，作为明确的范围外，包括它被混淆的原因。一个写明了原因的边界得以保持；一个只被排除的边界会在下次有人查看文件夹树时再次被跨越。
第二个问题：它的Lore处于什么状态？
| 来源状态 | 怎么做 |
|---|---|
| 有Lore，在一个领域中 | 直接联合它。 |
| 有标准但没有Lore（一个在没有它的情况下诞生的项目） | 首先在该项目上运行 transmute-lore add。标准是被拯救的，而不是被发明的。 |
| 原始材料，还没有领域拥有它 | 为该领域运行 create-area，然后运行 transmute-lore add，然后联合。 |
| 非文本（数据库、电子表格、Notion基础） | 首先提取为文本——模式转储、导出、pdftotext -layout。提取内容位于该领域的 fuente/ 中，永远不在机器人中。sync.js 只复制 .md、.txt 和 .json，因此任何未提取的内容都会对机器人静默不可见。 |
一个自由笔记收件箱（Obsidian vault 的 notas/，一个 Markdown 文件夹） | 永远不要联合。 它不包含Lore——它是原始经验，并且它是 .md，这恰恰是使错误变得容易的原因：sync.js 会愉快地复制它，路由表会将笔记列为标准。首先用 obsidian-lore 挖掘它；幸存的内容属于拥有它的领域，而机器人路由到那里。 |
将此盘点作为头脑风暴的一部分报告给用户，并附上真实的成本：每个缺乏Lore的来源都需要在机器人可以存在之前运行一次 create-area/transmute-lore。提议跳过它并“将所有内容提炼到机器人中”更快，但会产出一个无法维护的人工制品。
前提条件
目标领域存在，并且其 lore/ 中至少包含 identidad.md + principios.md。如果没有，停止并提议先运行 create-area——机器人像任何项目一样继承该领域的方法。
语言规则： 用用户的语言编写所有生成的内容——内容和人工制品文件名，而不是此技能编写的语言。
identidad.md、principios.md、FASES.md、proyectos/、canon/、enrutamiento.md是西班牙语规范形式：本地化它们。每种语言中固定的：CLAUDE.md、lore/、index.md、skills/、.claude-plugin/。领域内建立的名称优先；标记冲突，永远不要静默解决。
此技能旨在强制执行的法
一个机器人拥有三个具有三个不同所有者的标准主体。合并它们是默认的失败模式，并且它是无声的：一切仍然有效，而副本开始慢慢超越其来源。
| 主体 | 它是什么 | 规则 |
|---|---|---|
skills/{slug}/canon/ | 机器人是的标准——在每个决策前加载 | 提炼的；随技能移动 |
lore/ | 维护机器人的标准 | 项目自己的，像任何项目一样 |
| 借用的标准 | 每个其他项目的Lore | 通过指针访问，在其自己的地址；永远不是权威性的 |
三个名称是因为三个所有者。将它们区分开的测试：
来源是否可以丢弃？ 提炼会产生一个更小的东西，可以替换其来源。复制产生一个相同的东西，不能。
借用的标准通过指针访问，而不是通过副本。 路由表提供地址，生成的访问打开它，并且该Lore保持一个所有者和一个版本——与工具包其余部分运行相同的DRY规则，其中项目引用其领域的模块而不是复制它们。lore-ecosistema/（§7）仅针对一种情况将这些指针转换为副本，并且默认关闭。
以及使路由工作的法则：
按任务类型路由，而不是按项目名称。
一个实体可以拥有多个标准主体，其自身的准则禁止它们交叉。 常见的划分是它做什么 与它如何讲述——产品与传播——并且无论该实体是单个项目还是机器人服务的机构，这种划分都成立。命名它不会选择Lore：该机构在路由表中出现两次，这是有意为之。如果一项任务在两个之间模棱两可，询问——它比用错误的标准写出的六段文字更便宜。
从机器人实际服务的实体编写此部分。路由表是读者根据自己的情况检查的部分，而从另一个机器人带来的示例在看起来权威的同时会将他们引向错误的Lore。
程序
1. 询问用户——三个问题，用简单的语言
简单地说。 本文档很密集，因为它指导一个模型。与用户的对话不是。 在使用此技能时，不要说正典、联合、提炼、有效性边界、不变线索、反范围或Entre。说它们的意思：机器人始终知道什么、将其连接到、值得保留的标准、这在何处不再成立、一个规则、它不是为做什么。如果一个句子需要一个词汇表，重写该句子。
一次问一个，并用用户自己的话记录答案：
- ¿Cómo se va a llamar el bot?（这个机器人叫什么？）
- ¿Para qué lo vas a usar?（你打算用它做什么？）——自由文本。不要整理它；稍后会重新阅读以检查任务是否与声明的一致。
- ¿Dónde están las carpetas con la información que le va a servir?（那些包含将为它服务的信息的文件夹在哪里？）——要求路径。文件夹、数据库、文档转储、笔记。接受“todavía no sé”（还不知道）并继续：一个机器人可以只用一个来源创建并增长。
其他所有内容都从这三个问题中衍生出来，或从磁盘中读取。不要为此审问用户：
| 衍生 | 来源 |
|---|---|
{{BOT_SLUG}} | 名称，采用kebab-case；如果打包，这也是技能名称 |
{{BOT_TITLE}} | 给定的名称 |
{{AREA_PATH}} | 默认是 bots 领域——提议它，一行确认 |
{{MODE}} | 如果有现有来源则为 federar，如果没有则为 nuevo |
{{PURPOSE}} | 问题2的答案，逐字逐句 |
{{SOURCE_DOCS}} / {{ECOSYSTEM}} | 问题3的答案，在检查磁盘上的每个路径后 |
然后自己检查路径并在一张简短表格中报告你的发现——有多少文件，哪些已经有写下的标准，哪些是原始的。这份报告将问题3的答案变成步骤2的盘点。永远不要要求用户分类他们自己的文件夹。
2. 阅读上下文（在创建任何内容之前强制）
- 领域Lore：
identidad.md+principios.md(+index.md和主题模块)。 - 领域
FASES.md，以及任何已注册在其中的同级机器人。 - 源文档。 对于PDF，提取文本（
pdftotext -layout）。正典是从这些中提炼出来的——永远不是从模型对该主题的自身知识中。 - 仅
federar—— 首先盘点来源（见上表）。根据来源是否已有Lore对其进行分类，并找出那些需要在机器人能够联合它们之前运行create-area/transmute-lore的来源。在头脑风暴之前执行此操作：它改变了机器人第一天可以路由到的内容。 - 仅
federar： 阅读你计划路由到的每个Lore主体。你需要它的目的和它的反范围——反范围告诉你两个同级之间的边界在哪里，而边界是这里唯一真正可以提炼的东西。
3. 正典头脑风暴（硬门控）
调用 brainstorming。在设计被批准之前不要创建任何文件。 在此处强制执行§1中的简单语言规则——用用户自己的语言呈现设计。
…