create-bot — 建立一個機器人：一個可安裝的工作場所
建立一個 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 工作區——這些都未經提煉。這些素材無法被聯邦化 (federated)，而解決方案是一個鏈條，不是捷徑：
原始來源 (無 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 基地) | 先提取為文字 — schema 轉儲、匯出、pdftotext -layout。提取的內容會存放在該區域的 fuente/ 中，絕不存放在機器人中。sync.js 只複製 .md、.txt 和 .json 檔案，因此任何未提取的內容都會對機器人無聲地不可見。 |
自由筆記收件匣 (Obsidian 筆記庫的 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。說它們代表的意思：機器人始終知道的東西、將其連接起來、值得保留的判斷標準、這在什麼情況下不再成立、一條規則、它不是用來做什麼的。如果一個句子需要詞彙表，請重寫該句子。
一次問一個，並以使用者自己的話記錄答案：
- 這個機器人要叫什麼名字？
- 你要用它來做什麼？ — 自由文字。請勿整理；稍後會重新閱讀以檢查任務是否與宣告的一致。
- 包含它將使用的資訊的資料夾在哪裡？ — 要求提供路徑。資料夾、資料庫、文件轉儲、筆記。接受「我還不知道」並繼續：一個機器人可以只有一個來源並持續成長。
其他所有東西都是從這三個答案推導出來的，或是從磁碟讀取。不要為此審問使用者：
| 推導項目 | 來源 |
|---|---|
{{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 節的白話文規則——用...
…（內容截斷以利翻譯）