create-bot — ボットを構築する：インストール可能な作業場所
ボットを作成します。これはClaude Codeのプラグイン、Loreのプロジェクト、そして作業セッションを開く場所を兼ねるフォルダです。ボットはプロジェクトに関する質問に答えるのではなく、プロジェクト内で作業を行います。指示が入力されると、ボットは実際のファイルに対してそれを実行し、結果を返します。
北極星、そして唯一重要なテスト： 短い指示で十分であること。 もし結果を得るためにプロジェクトをボットに説明する必要があったなら、読み込み時に判断基準が不足していたことになります。
ボットとは何か、何でないか
create-botはcreate-projectの兄弟であり、create-areaの兄弟ではありません。標準パスはbots/proyectos/{slug}/ です。botsはボットをホストするエリアであり、webエリアがウェブサイトをホストするのと同じです。そのエリアがまだ存在しない場合、create-areaが他のプロジェクトと全く同様に最初に作成します。ユーザーが指定した場合、別のエリアがボットをホストすることも可能です。その場合は仮定せずに従ってください。
| エリア | プロジェクト | ボット | |
|---|---|---|---|
| 保持するもの | プロジェクト | 1つの作業 | 作業セッション |
| そのLoreが支配するもの | ドメインの手法 | その作業 | エージェントの振る舞い方 |
| 開かれて行うこと | レジストリを確認する | その作業を進める | 複数のプロジェクトのいずれかで作業する |
ボットは、このキットの中で外部へルーティングする唯一のアーティファクトです。エリアとプロジェクトは場所であり、ボットはそれらに持ち込むレンズです。
ボットは自動的にプラグインにはなりません。 デフォルトでは、正典と
CLAUDE.mdを含むフォルダです。そこでセッションを開けば、何もインストールせずに判断基準が既に読み込まれています。.claude-plugin/と独自のリポジトリでスキルとしてラップすることはオプションの封印（§10）であり、チームに渡すという1つの目的にのみ役立ちます。一人で作業する場合、それは維持管理が必要な足場に過ぎません。
なぜエリアであってはならないか。 エリアはプロジェクトのコンテナであり、そのドメインの判断基準を所有します。ボットはルーティング先の判断基準を何も所有しません。借用するのです。エリアとして構築すると、決して支払ったことのない判断基準を蓄積する親が作成され、その最初の結果はすぐに現れます。判断基準が一般化されると、それを獲得したエリアではなく、ボットに昇格されてしまうのです。
2つのモード
| モード | タイミング | 生成物 |
|---|---|---|
nuevo | ゼロから。収集すべき既存のLoreがない場合。 | ブレインストーミングとソースドキュメントから生まれた正典。 |
federar | 判断基準が既に存在し、複数のエリアに分散している場合。 | 正典に加えて、同期コピーとそれらのLoreボディに対するルーティングテーブル。 |
両方とも同じアーティファクトを生成します。federarはscripts/ecosistema.json、scripts/sync.js、および2つの生成ファイル（lore/enrutamiento.md（ルーティングテーブル）と.claude/settings.local.json（ライブツリーへのアクセス））を追加します。コピーが有効になっていない限り（§7）、何もコピーしません。
ボットが既に存在する場合
上記の2つのモードはゼロから構築しますが、これがこのスキルが呼び出される唯一の方法ではありません。既にツリー内にあるボットを指して、スコープの修正、READMEの書き換え、ソースの追加を行うこともあります。以下の監査を作成手順の代わりに実行し、その後§7（同期）、§10（パッケージング）、§11（検証）に再参加します。
| チェック | 方法 | 失敗条件 |
|---|---|---|
| スコープ | マニフェストの各エントリを組織のレジストリと比較する | レジストリにリストされていないソースがルーティングされている |
| 境界 | 正典の範囲外宣言を読む | 境界線上にあるプロジェクトが欠落しているか、混乱の理由なしにリストされている |
| 孤立 | lsで同期先をマニフェストと比較する（コピーが有効な場合のみ） | ソースがマニフェストに存在しないフォルダが残っている |
| コピー | 誰がボットを使用しているか、そのツリーを持っているかを尋ねる | 全員がフォルダツリーを共有しているのにlore-ecosistema/が有効になっている — 読み手のいない重複 |
| README | 作者としてではなく、読者として読む | 手法を論じているか、例がボットがもうサービスを提供していないプロジェクトに関するもの |
| インストール | コマンドを実行し、読まない | 記憶から書かれたか、公開ボットからコピーされた |
| ゲート | node scripts/validar.js（パッケージ化されている場合） | ゼロ以外の終了コード |
監査は軽い手続きではありません。これは新規ビルドでは見つけられないものを見つけます。ボットがサービスを提供するために構築されたものと現在サービスを提供しているものとの間の乖離であり、これは誰も自分では再導出しないものです。
ソースにまだLoreがない場合
一般的な出発点は、整然としたLoreボディのセットではありません。それは生の素材です。ドキュメントのフォルダ、コードベース、データベース、Notionワークスペース — どれも蒸留されていません。その素材は統合できず、修正は、近道ではなく、連鎖です。
生のソース（Loreなし）
└─ create-area → この判断基準を所有する作業エリア
└─ transmute-lore (追加) → 内部に散在する判断基準を回復
└─ create-bot (統合) → ボットがそれをルーティング
法則：ボットは決して自身に蒸留してはならない。 Loreのないソースは、それを所有するエリア内でLoreを得て、その後で初めて統合されます。ボットが生の素材を直接蒸留することを許せば、決して獲得していない判断基準の所有者になり、エリア/ボットの区別が防止するために存在するまさにその失敗が起こり、実際には元に戻せません。一度その判断基準の唯一のコピーがボット内に存在すると、エリアはもはやその真実のソースになれなくなります。
具体的には、以下のステップ2で、何かを設計する前にすべてのソースを棚卸しします。棚卸しには2つの質問があり、所有権が最初に来ます。
最初の質問：これは組織に属するものか？
ボットのスコープは、それがサービスを提供する組織のレジストリから来ます。決して構築マシンのフォルダツリーからではありません。
ソースにLoreがあるかどうかを尋ねる前に、それが誰のものかを尋ねてください。組織自身のレジストリ（FASES.md、カタログ、憲章）を開き、ソースがそこにリストされていることを確認してください。リストされていない場合、マニフェストには含まれません。
これが後のチェックではなく最初のゲートである理由： 失敗は静かに起こります。ビルダーのプロジェクトツリーを歩いて満たされたマニフェストは、完全で内部的に一貫しているように見えながらも間違っているルーティングテーブルを生成し、その後誰もそれを再導出しません。ディスク上の近接性が組織のメンバーシップと一度誤解され、その後継承されます。
境界上のソースは、単に省略されるのではなく、宣言されます。 組織と人を共有するプロジェクト、公開ショーケースに現れるプロジェクト、またはボット自身の最初のユースケースであったプロジェクトは、属しているように見えます。それを正典に明示的に範囲外として、混乱する理由とともに配置してください。理由とともに書かれた境界は保持されます。単に除外された境界は、次回誰かがフォルダツリーを見たときに再び越えられます。
2番目の質問：そのLoreの状態は？
| ソースの状態 | すべきこと |
|---|---|
| Loreがあり、エリア内にある | 直接統合する。 |
| 判断基準はあるがLoreがない（Loreなしで生まれたプロジェクト） | まずそのプロジェクトでtransmute-lore 追加 を実行する。判断基準は救出され、決して発明されない。 |
| 生の素材、まだ所有するエリアがない | ドメインにcreate-areaを実行し、次にtransmute-lore追加、その後統合する。 |
| テキストではない（データベース、スプレッドシート、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/。エリアの確立された名前はそのツリー内で優先されます。競合はフラグを立て、静かに解決しないでください。
このスキルが存在する理由である法則
ボットは3つの異なる所有者を持つ3つの判断基準のボディを保持します。それらをマージすることがデフォルトの失敗モードであり、それは静かに起こります。すべてはまだ機能し、コピーはゆっくりとそのソースよりも上位になります。
| ボディ | 内容 | ルール |
|---|---|---|
skills/{slug}/canon/ | ボットである判断基準 — すべての決定の前に読み込まれる | 蒸留され、スキル内に移動する |
lore/ | ボットを維持するための判断基準 | 他のプロジェクトと同様に、そのプロジェクト自身のもの |
| 借用された判断基準 | 他のすべてのプロジェクトのLore | ポインタによって、自身のアドレスで到達される。決して信頼できない |
3つの名前は3つの所有者のためです。それらを分離するテスト：
ソースは破棄可能か？ 蒸留は、その起源を置き換えることができるより小さなものを生成します。コピーは、できない同一のものを生成します。
借用された判断基準は、コピーではなくポインタによって到達されます。 ルーティングテーブルはアドレスを与え、生成されたアクセスがそれを開き、そのLoreは1つの所有者と1つのバージョンを保持します。これは、プロジェクトがモジュールを複製する代わりにエリアのモジュールを参照する、キットの残りが実行しているのと同じDRYルールです。lore-ecosistema/（§7）は、1つの状況のみのためにそれらのポインタをコピーに変換し、デフォルトではオフになっています。
そして、ルーティングを機能させる法則：
プロジェクトの名前ではなく、タスクの種類によってルーティングする。
1つのエンティティが、自身の原則がそれらの交差を禁じる複数の判断基準のボディを所有することができます。 一般的な分割は、それが何をするか対それをどう伝えるか — 製品対コミュニケーション — であり、エンティティが単一のプロジェクトであろうとボットがサービスを提供する組織であろうと同じです。名前を付けてもLoreは選択されません。組織はルーティングテーブルに意図的に2回現れます。タスクが2つの間で曖昧な場合は、尋ねてください — それは間違った判断基準に基づいて書かれた6つの段落よりも安価です。
このセクションは、ボットが実際にサービスを提供するエンティティから書いてください。ルーティングテーブルは、読者が自分のケースに対してチェックする部分であり、別のボットから持ち込まれた例は、権威があるように見えながら読者を間違ったLoreに導きます。
手順
1. ユーザーに尋ねる — 3つの質問、平易な言葉で
平易に話すこと。 このドキュメントはモデルに指示するために密集しています。ユーザーとの会話は違います。 このスキルを使用している間は、canon、federate、distill、boundary of validity、invariant clue、anti-scope、Entreと言わないでください。それらが意味することを言ってください：ボットが常に知っていること、それに接続する、保持する価値のある判断基準、これが真実でなくなる場所、ルール、それが何のためではないか。文に用語集が必要なら、文を書き直してください。
一度に1つずつ尋ね、答えをユーザー自身の言葉で受け取ってください。
- ¿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?（情報が入っているフォルダはどこですか？） — パスを尋ねてください。フォルダ、データベース、ドキュメントダンプ、ノート。「まだわかりません」を受け入れ、続行してください。ボットは1つのソースで作成し、成長させることができます。
その他はすべて、これら3つから導出されるか、ディスクから読み取られます。ユーザーにそれを尋問しないでください。
| 導出されるもの | 元 |
|---|---|
{{BOT_SLUG}} | 名前をケバブケースに。パッケージ化されている場合、これがスキル名でもあります |
{{BOT_TITLE}} | 与えられた名前そのまま |
{{AREA_PATH}} | デフォルトでbotsエリア — 提案し、1行で確認する |
{{MODE}} | 既存のソースがあればfederar、なければnuevo |
{{PURPOSE}} | 答え2を逐語的に |
{{SOURCE_DOCS}} / {{ECOSYSTEM}} | 各パスをディスクで検査した後の答え3 |
次に、自分でパスを検査し、見つけたものを1つの短い表で報告してください。ファイル数、既に判断基準が書き留められているもの、生のもの。そのレポートが、答え3をステップ2の棚卸しに変えます。ユーザーに自分のフォルダを分類するよう決して求めないでください。
2. コンテキストを読む（何かを作成する前に必須）
- エリアのLore：
identidad.md+principios.md（+index.mdとテーマ別モジュール）。 - エリアの
FASES.md、およびそこに既に登録されている兄弟ボット。 - ソースドキュメント。 PDFの場合は、テキストを抽出します（
pdftotext -layout）。正典はこれらから蒸留されます — モデル自身のトピックに関する知識からではありません。 federarのみ — 最初にソースを棚卸しする（上の表を参照）。すべての意図されたソースを、既にLoreがあるかどうかで分類し、ボットが統合する前にcreate-area/transmute-loreが必要なものを明らかにします。これをブレインストーミングの前に行ってください。これにより、初日にボットがルーティングできるものが変わります。federarのみ： ルーティング先の各Loreボディを読んでください。その目的とアンチスコープが必要です。アンチスコープは、2つの兄弟の間の境界がどこにあるかを示し、その境界こそがここで真に蒸留可能な唯一のものです。
3. 正典のブレインストーミング（ハードゲート）
brainstormingを呼び出します。設計が承認されるまでファイルを作成しないでください。 §1の平易な言葉のルールをここでも適用し、設計を…
[翻訳のため省略]