eiirp

EIIRP — すべてをあるべき場所に

「すべてをあるべき場所に」 — Radiohead、Kid A

契約

重要な作業の後、EIIRP は2つの領域にわたるすべての成果物を整理します。

知識領域（脳）：

1. すべての知識を、脳の適切な場所に保存します。
2. すべての情報源を引用し、リンクします。
3. 新しいコンテンツタイプが生まれた場合は、アクティブなスキーマパックを更新します。
4. エンティティページを作成・更新し、相互リンクを追加します。

機能領域（スキル）： 5. 再利用可能なパターンをすべて、組み合わせ可能なスキルにします。 6. DRY 違反がないか、既存のスキルを監査します。 7. スキルグラフは MECE で、抜け漏れや重複がなく、振り分け先が曖昧でない状態にします。

メタ保証： 重要な作業中に生み出されたものが、チャット内にしか存在しない状態にはなりません。 知識 → 脳。パターン → スキル。すべてをあるべき場所に。

使用するタイミング

• 詳細な調査スレッドを完了した後。
• 新しいもの（コード、パイプライン、ワークフロー）を構築した後。
• 複数の情報源を分析し、重要な知見が得られた後。
• ユーザーが「EIIRP」「これを整理して」「DRY にして」「再現できるようにして」と言ったとき。
• 作業セッションで、知識と新しい機能の両方が生まれたとき。
• スキルの重複、複製、抜け漏れに気づいたとき。

自動実行ゲート — 提供前にファイルへ保存（常時有効）

規約： conventions/brain-first.md を参照してください。 — これは書き込み側の規約です。実質的な分析は、チャット内だけでなく 脳に保存します。

ユーザーが作業セッション後に実行する前述の7フェーズ監査とは異なり、このゲートは signal-detector のような常時有効なエージェント側の規約です。トリガーフレーズによってここに誘導されたときではなく、実質的な返答のたびにエージェントが適用します。常時有効とは、適切に動作するエージェントが従うハーネスのルーティング規約であり、機械的な保証ではありません。スキルが読み込まれなかった場合に、gbrain ランタイムが返答をブロックすることはありません。

評価するのは依頼時ではなく、提供時です。 ユーザーから共有された文書について実質的な分析（構造化された出力が500語以上）を提供しようとする時点で、ゲートが評価します。分析が完了し、返答を作成している段階です。その時点で、まず脳のページをファイルに保存し、そのページへのリンクを添えて分析を同じ返答で提供します。ユーザーに「これをファイルに保存しましたか？」と尋ねさせてはいけません。

実行条件（3つすべてを満たすこと）

1. ユーザーが文書を共有していること — PDF、添付ファイル、文書へのリンク、または貼り付けられた長文コンテンツ。
2. 提供しようとしている返答に、実質的な分析が含まれること：構造化された出力が500語以上（所見、推奨事項、抽出データなど。単なる言い換えや書式設定は除く）。
3. 内容が再度見つける価値のある知識であること — 数か月後に脳を読む人が、このページを必要とするかどうか。

実行しない場合

• 簡単な質問（「X は何ページにある？」「これに記載されている日付は？」）。
• 単純な検索、または文書を変更せずに転送する場合。
• 純粋に運用上の内容（タスクリスト、カレンダー項目、状況報告）。
• 専用パイプライン（次のリスト）を通じてすでに処理されている文書。
• 自動ファイリングをオフにしているユーザー（ストレージポリシーは下記）。

専用パイプラインによる除外

これらのパイプラインは、脳への書き込み処理を独自に行います。ゲートは重ねてファイルに保存してはいけません。これらのいずれかが適切なルートである場合は、それを実行し、保存処理を任せます。

• skills/meeting-ingestion/SKILL.md — 文字起こし＋参加者情報の反映
• skills/idea-ingest/SKILL.md — 著者・出版情報を含む記事
• skills/media-ingest/SKILL.md — ファイルの一括取り込み
• skills/voice-note-ingest/SKILL.md — 音声メモ
• skills/book-mirror/SKILL.md — パーソナライズされた書籍ミラー

ファイルへの記録手順（返信を送信する前に）

1. パス — skills/brain-taxonomist/SKILL.md を確認します。アクティブなスキーマパック（gbrain schema show --json）を読み込みます。ドキュメント分析は通常 analysis/ または research/ に、エンティティ中心の調査結果は people/ または companies/ に保存します。

2. 書き込み — capture 経由でファイルに記録します。

   gbrain capture --file <analysis.md> --slug <taxonomist-path>
   

   （または、シンクライアントのインストールでは MCP 経由で put_page を使用します）。Phase 4a に従って完全なフロントマターを付けます。ページは自己完結している必要があります。数か月後に読む人が、チャットスレッドを見なくても全体像を把握できるようにします。

3. 同じ返信内でリンクする — 分析内容を返信に記載し（会話形式で、「brain ページを参照」とするだけでは不十分です）、記録したページへのリンク行を添えます。リンクの形式とリンク先の検証手順は skills/brain-link-discipline/SKILL.md に従います。複数のページがある場合は、すべてのリンクを列挙します。

4. 初回通知。 このゲートがユーザーに対して初めて動作したときは、自動記録が始まるタイミングで知らせられるよう、配信する返信に次の一行を追加します。後からではなく、開始時に通知してください。Auto-filed to <path>; say "stop auto-filing" to disable. 通知済みであることを（ユーザーごとの保存ポリシーのメモに）記録し、二度と繰り返さないようにします。あるいは、セットアップ時に一度だけ確認し、最初の書き込み前にポリシーを記録します。

ユーザーごとの保存ポリシー

自動記録はデフォルトであり、強制ではありません。ユーザーごとの保存ポリシーに従います。ユーザーがドキュメント分析の自動記録を停止するよう求めた場合（または特定のドキュメントをチャットのみで扱うよう求めた場合）は、その設定を記録し、ゲートを動作させないようにします。ページを作成せずに分析結果を提供します。リクエストがあれば再び有効にします。

7 フェーズ監査との関係

このゲートは、単一の成果物に対するショートカットです。1 つのドキュメントから 1 つのページを作成し、そのページへのリンクを配信する返信に含めます。作業セッション全体では、以下の完全な EIIRP パスが必要です。このゲートは、個々の分析がその完了を待たずに済むようにするだけです。

フェーズ 1：INVENTORY — 何を作成したか？

現在のセッション／スレッドを確認し、両方の領域にわたるすべての出力を特定します。

ナレッジの出力

□ Primary findings (the synthesis)
□ Source documents (URLs, PDFs, articles, tweets)
□ Entity mentions (people, companies, organizations, places)
□ Concepts/frameworks (reusable mental models)
□ Data artifacts (structured data, timelines, statistics)

機能の出力

□ New skills created or modified
□ Scripts/code written (should they be in lib/ or scripts/?)
□ Methodology used (search patterns, source chains, verification steps)
□ Workflows that could be automated (cron, pipeline, webhook)
□ Patterns that will recur (→ candidate for skillification)

マニフェストを作成します。

## EIIRP Manifest
- Topic: [topic]
- Date: [date]
- Knowledge outputs: [count] (sources, entities, concepts)
- Capability outputs: [count] (skills, scripts, patterns)
- Reusable methodology: [yes/no — describe if yes]

フェーズ 2：TAXONOMY — それぞれの内容をどこに配置するか？

まずアクティブなスキーマパックを読み込みます（v0.39 以降の記録判断における唯一の信頼できる情報源です）。

gbrain schema show --json

パックの page_types[] には、brain が受け入れるすべてのディレクトリと、それぞれが対応するプリミティブが記載されています。各出力について確認し、コンテンツの主な対象に path_prefixes が一致するディレクトリを選びます。

brain-taxonomist がインストールされている場合、判断に迷うケースではこれを呼び出します。アクティブなパックに基づいて同じ判断手順を実行し、推奨する記録先のパスを理由とともに 1 つ提示します。

出力：記録計画の表

| Content | Brain path | Action |
|---------|-----------|--------|
| Primary research | reference/.../page.md | CREATE |
| Person X | people/x-slug.md | CREATE |
| Person Y | people/y-slug.md | UPDATE (already exists) |
| ... | ... | ... |

フェーズ 3：SCHEMA CHECK — アクティブなパックはこの内容に対応しているか？

ここで EIIRP はスキーマ導出のループを完了します。作業で作成した内容が既存の page_types に該当しない場合は、v0.39 の cathedral を使って新しいタイプの追加を提案します。

# What's emerging in the brain that the active pack doesn't cover?
gbrain schema detect --json

# LLM-refined suggestions (heuristic when no API key set).
gbrain schema suggest --json

# Review what's pending; promote or ignore each candidate.
gbrain schema review-candidates --json
gbrain schema review-candidates --apply <prefix-or-type-name>

信頼度の下限： gbrain schema suggest が提案されたタイプに対して 0.6 未満の信頼度を返した場合、自動適用してはいけません。提案をユーザーに提示し、判断を委ねます。schema-cathedral はプリミティブを提供し、EIIRP は人間が関与するゲートを適用します。

スキーマの変更が必要な場合：

• review-candidates --apply を実行する前に、追加案をユーザーに提示します。
• 次回の同期時のコミットメッセージに、変更内容を記録します。
• schema-pack エンジンは変更差分を ~/.gbrain/schema-pack-deltas/ に書き込みます。内容を確認し、gbrain schema edit（または YAML の手動編集）を使ってアクティブなパックに統合します。

フェーズ 4：FILE — 情報を充実させた brain ページを作成する

記録計画にある各項目について：

4a. 主要な調査ページ

brain ページのテンプレートを使用します。必ず以下を含めてください。

• 適切なフロントマター（type、title、date、tags、sources）
• State セクション — 現在の状況／主な調査結果
• Sources セクション — 各情報源の URL、著者、日付、言語
• Timeline セクション — 時系列順の進展
• Entity links — 関連するすべての brain ページへのバックリンク
• See Also — 関連する概念、参照ページ

4b. エンティティページ（人物、企業）

言及されたエンティティごとに、以下を行います。

• brain ページが存在するか確認します（gbrain search "<name>" または gbrain get people/<slug>）。
• 存在する場合：State を更新し、この調査を引用する Timeline エントリを追加します。
• 存在しない場合：情報を補完して作成します。

4c. コミットと検証

すべてのページを書き終えた後、gbrain sync を実行します（または brain リポジトリでコミットしてプッシュします）。すべてのリンクが解決されることを確認します。

フェーズ 5：スキルグラフの監査 — 機能に関する DRY + MECE

このフェーズでは、調査対象だけでなく、スキルグラフも対象にします。

読み取り専用プラグインのインストール： 同梱されているプラグインのスナップショットは書き込みできません。新規または更新するスキルと lib/ への抽出先は、同梱スナップショットではなく、自分のプロジェクトのスキルディレクトリまたは brain 内のスキルパック（gbrain skillpack init-brain-pack）にします。フェーズ 1〜4 とフェーズ 6 の gbrain CLI チェックは、どの環境でも実行できます。

5a. 新しいパターンの特定

今回の作業で、今後も繰り返し使われる可能性のあるパターンが明らかになったかを確認します。

再利用可能なパターンの指標：

• 複数の情報源に対して、特定の検索手順を使用した。
• 特定の検証／相互参照の方法に従った。
• 入力を変えられるコードを書いた。
• 出力形式を一般化できる。
• ユーザーが別のトピックについて同様の作業を依頼する可能性が高い。

特定したパターンごとに、以下を行います。

1. 組み合わせ可能な要素を特定します（DRY、MECE）。
   • 共通ロジック → lib/（スキルにコピー＆ペーストしない）
   • 検索方法 → スキルまたは lib 関数
   • 出力テンプレート → brain テンプレートまたはスキルのフェーズ
   • 分類ロジック → brain-taxonomist + アクティブパックで対応済み
2. v0.19 リゾルバーで DRY を確認します。

   gbrain check-resolvable
   

   トリガーの重複や、到達不能なスキルがないか確認します。

5b. 既存スキルの監査

今回の作業で使用または変更したすべてのスキルについて、以下を確認します。

1. バイパスしたスキルはありますか？（スキルが対応すべき作業を手動で行いませんでしたか？）
2. 今回の作業と重複するスキルはありますか？（統合候補）
3. スキル間で共通コードをコピー＆ペーストしていませんか？（lib/ に抽出）

MECE の確認事項： 明日、別のトピックでまったく同じ作業を依頼された場合、どのスキルが呼び出されますか？その経路は明確で一意ですか？そうでない場合は、ルーティングを修正します。

5c. 計画の提示

## Skill Graph Changes

### New skills to create
1. **[skill-name]** — [what it does]
   - DRY check: [clean / overlaps with X]
   - Recommendation: [create / merge into X]

### Existing skills to update
1. **[skill-name]** — [what changed, why]

### Code to extract to lib/
1. **lib/[name].ts** — [what it does, which skills use it]

### Skills to merge or deprecate
1. **[skill-A] + [skill-B]** → [merged-skill] — [why]

承認後、新規または変更したスキルごとに /skillify を呼び出します。

フェーズ 6：CHECK_RESOLVABLE — すべてのルーティングを検証

すべての分類とスキル化が完了した後、以下を実行します。

gbrain check-resolvable                         # routing-table reachability
gbrain doctor --json                            # health surface
gbrain search "<topic keywords>"                # brain pages findable
gbrain orphans                                  # any pages without inbound links?

以下を確認します。

• すべての brain ページが、アクティブなスキーマパックに準拠した適切なフロントマターを備えている
• すべてのエンティティページが相互にリンクされている
• 新しいスキルがある場合、skills/RESOLVER.md にルーティングエントリがある（スキルツリーに書き込み可能な場合）
• DRY 違反がない（スキル間でロジックが重複していない）
• MECE 違反がない（スキル間のルーティングが曖昧でない）
• 新しいコンテンツタイプが追加された場合、アクティブなスキーマパックが更新されている
• gbrain schema review-orphans --json の結果が orphan_count: 0 である（型が設定されていないページや、宣言されていない型がない）

フェーズ 7：レポート — 要約

## EIIRP Complete: [Topic]

### Brain pages created/updated
- [path] — [description]
- ...

### Entity pages
- [path] — [created/updated]
- ...

### Schema changes
- [none / description of changes + which pack delta file]

### Skills identified
- [skill-name] — [status: created / merged / deferred]
- ...

### Resolver status
- DRY check: [clean]
- MECE audit: [clean]
- Active pack: [name] v[version]
- schema review-orphans: [orphan_count 0 / N untyped + M undeclared-type pages]

出力形式

EIIRP は、単一のフェーズ 7 レポートブロックを生成します。プレーンな Markdown 形式です。

## EIIRP Complete: [topic]

### Brain pages created/updated
- [path] — [description]

### Entity pages
- [path] — [created|updated]

### Schema changes
- [none | description of changes + which pack delta file]

### Skills identified
- [skill-name] — [status: created|merged|deferred]

### Resolver status
- DRY check: [clean|N violations]
- MECE audit: [clean|N overlaps]
- Active pack: [name] v[version]
- schema review-orphans: [0 orphans|N untyped + M undeclared-type pages]

常に機械可読にします。セクション見出しを固定し、項目ごとに箇条書きにします。このレポートは、後続のスキルにとって同期チェックポイントとしても機能します（skillpack-check が読み取り、doctor がパックのバージョンと照合します）。

失敗した場合

gbrain のエラー code、終了コード、[AGENT] ブロック、または通知ブロックについては、エージェントオペレータープロトコルに従ってください。このスキルに固有の注意事項は次のとおりです。

• スキーマの変更（gbrain schema add-type、gbrain schema use）にはユーザーの確認が必要です。確認を求め、ユーザーが拒否した場合は停止してください。
• gbrain schema suggest は API キーなしでヒューリスティックのみを実行します。提案はヒューリスティックによるもので、LLM による改良は行われていないことを伝えてください。
• 書き込み処理が revision_conflict または write_pending（終了コード 10）を返した場合は、再読み込みしてマージするか、gbrain write-request <request_id> をポーリングしてください。Phase 7 のレポートでは、保留中の書き込みは保留中として記載します。

アンチパターン

• EIIRP のロジックにディレクトリテーブルをハードコードすること。 すべての記録先の判断で gbrain schema show --json を読み込みます。gbrain-recommended を使用するユーザーにも、カスタムパックを使用するユーザーにも、自動的に正しい動作を提供する必要があります。
• 信頼度の低いスキーマ提案を自動適用すること。 gbrain schema suggest の信頼度が 0.6 未満の場合は、手動での確認が必要です。EIIRP が提案を提示し、ユーザーが承認します。
• 「これは一度きりの作業だから」と Phase 5 の SKILL GRAPH AUDIT を省略すること。 作業に 10 分を超える時間がかかったなら、その手法は再利用できる可能性があります。必ず監査し、スキル化するかどうかの判断はユーザーに委ねてください。
• トピックだけを基準に統合結果を記録すること。 1 つのソースと読者に結び付いた統合ページは固有のものであり、media/<format>/<slug>-personalized.md に記録します。「Sanctioned exception」セクションの _brain-filing-rules.md を参照してください。
• 英語以外のソースを二次的な引用として扱うこと。 多言語のソースも同等に扱います。
• 相当量のドキュメント分析を、記録済みページとリンクなしで提供すること。 自動実行ゲートは、まず記録を行い、その後、同じ返信で分析とリンクを提供します。「ページを作成します」と将来の作業として述べてはいけません。後続メッセージでリンクを送ったり、ユーザーに求められるまで待ったりしてはいけません。
• 専用パイプラインのコンテンツを二重に記録すること。 会議の文字起こし、記事、大量のメディア、音声メモ、書籍のミラーには、それぞれ固有の脳への書き込みロジックを持つ取り込みスキルがあります。ゲートはこれらを対象外とします。
• ユーザーが無効にした後も自動記録すること。 自動記録はユーザーごとのストレージポリシーの既定値であり、必須ではありません。記録された設定を尊重してください。

厳守事項

ナレッジ領域

• 調査内容をチャット内だけに残してはいけません。 作成に 10 分を超える時間がかかった場合は、ブレインページを作成します。
• すべてのソースに引用を付けます。 URL なしで「報道によると」と記載してはいけません。
• エンティティページは新規作成するだけでなく更新します。 ブレインページがすでに存在する場合は、更新してください。
• スキーマの変更には確認が必要です。 アクティブなパックは重要な基盤です。
• 多言語のソースも同等に扱います。 英語以外のソースを二次的なものとして扱ってはいけません。

機能領域

• DRY は絶対です。 同じロジックが 2 つのスキルに現れる場合は、lib/ に抽出してください。
• MECE は絶対です。 すべてのトリガーフレーズは、必ず 1 つのスキルだけに振り分けます。
• モノリスより合成性を優先します。 小さなスキルを組み合わせるほうが、すべてを処理する巨大なスキル 1 つより優れています。
• 繰り返し発生するものだけをスキル化します。 一度きりの作業をスキルにする必要はありません。2 回以上繰り返されるパターンはスキル化します。

メタ

• EIIRP は冪等です。 同じ作業に対して 2 回実行した場合、2 回目には変更が発生しないようにします。
• EIIRP はアクティブなスキーマパックをデータとして利用します。 EIIRP のロジックにディレクトリテーブルをハードコードしてはいけません。gbrain schema show --json から読み込み、gbrain-recommended を選んだユーザーにもカスタムパックを選んだユーザーにも、自動的に正しい動作を提供してください。

変更履歴

v1.1.0 — 自動実行ゲートの統合（上流の詳細分析自動登録スキルから）

• 常時有効な自動実行ゲートを統合しました。ユーザーが共有したドキュメントについて、構造化された分析が500語以上になり、まもなく提供される場合は、まず脳ページを登録し、その後、同じ返信で分析とリンクを提供します。
• 登録には、提供元の git commit の仕組みではなく、brain-taxonomist（アクティブなスキーマパック）と gbrain capture を使用します。提供元の GitHub API による直接リンク確認は省き、brain-link-discipline スキルのリンク形式と検証手順を採用しました。
• CLAUDE.md のプライバシールールに従い、提供元の例と由来の説明を一般化しました。専用パイプラインの適用除外と、ユーザーごとのストレージポリシーを無効にするスイッチを追加しました。

v1.0.0 — gbrain v0.39.0.0

• 上流の OpenClaw から初期移植しました。CLAUDE.md のプライバシールールに従い、非公開フォーク名への言及はありません。
• フェーズ3の SCHEMA CHECK を書き換え、非公開の brain/schema.md ではなく、v0.39 cathedral CLI （detect | suggest | review-candidates）を使用するようにしました。
• フェーズ5の SKILL GRAPH AUDIT では、上流の scripts/skill-dry-check.mjs ではなく、gbrain check-resolvable を呼び出します。
• フェーズ6の検証では、gbrain schema review-orphans を使用します（型が設定されていないページと未宣言の型を対象とし、schema lint --with-db と同じ分類です）。MCP 経由では、run_doctor の schema_pack_consistency チェックで同じ判定を行います。