Letterbox

📌 社内本番利用のために構築されました。 数か月にわたる日常的な AI 開発で実証済みのアーキテクチャです。リファレンス実装としてオープンソース化されています。

平たく言うと: ターミナルで AI コーディングアシスタントを使う場合、通常は一度に 1 つずつ作業します。2 つを連携させるには、自分でウィンドウ間でメッセージをコピー＆ペーストする必要があります。Letterbox を使うと、2 つのアシスタント（たとえば Claude と Gemini、または Gemini と Mistral の Vibe）が直接会話し、ハンズフリーでタスクを一緒に進められます。

結果: 一方のエージェントが計画を立て、もう一方がレビューする、または 2 つで作業を分担する — すべてのメッセージを手動で中継する代わりに、あなたが見ている前で自律的に協力します。

別々のターミナルで動作する 2 つの AI エージェントがリアルタイムに会話できる、ファイルベースの小さな通信プロトコル。

Letterbox を使うと、Claude Code、Gemini CLI、Antigravity、Mistral の Vibe といった 2 つのターミナルコーディングエージェントが、共有ディレクトリを介してメッセージファイルを渡し合うことでリアルタイムの会話を実現します。一方のエージェントが発言すると、📬 通知がもう一方のターミナルに注入され、それを読んで返信するよう起こします。ネットワークもサーバーも共有メモリも不要です。フォルダ内の JSON ファイルと OS のアトミックリネームだけです。これは社内のプランニングループ用に構築されたメッセージングレイヤーで、2026 年にスタンドアロンのバージョン管理されたツールとして抽出されました。2 つの CLI エージェントに、ウィンドウ間のコピー＆ペーストなしでタスクを協力させたいと思ったことがあるなら、これが最適です。作者の気まぐれで時々更新されます（ランチャーが新しいバージョンの存在を通知します）が、サポートはありません。ロードマップも機能リクエストもなく、コミュニティプロジェクトでもありません。

このブリッジは真にクロスハーネスです。片側に Claude、もう片側に Gemini が同じチャネルで会話することがライブで検証されています。唯一の難点はセットアップです。Claude は自動的に配線されますが、Gemini と Antigravity は独自の設定から letterbox を読み込みます。セットアップセクションで両方を説明します。

存在理由

私は毎日 2 つの AI コラボレーター（Claude と Gemini）と仕事をしています。それぞれが実行されるターミナルハーネス（Claude Code、Gemini CLI、Antigravity CLI、そして現在は Mistral の Vibe）の中に存在します。Letterbox は、私を介さずに互いに会話させるための方法です。

これは 2 つのモードで発生します。手動の場合もあります。ブレインストーミング中に、もう一方のモデルを会話に参加させたい場合です。自動の場合もあります。プランニングループでは、Claude が計画を起草し、各計画が組み込みステージとして Gemini にレビュー用にルーティングされます。Letterbox は両方を同じ方法で運びます。

設計上、ハーネスに依存しません。Claude Code ↔ Gemini CLI ↔ Antigravity CLI ↔ Vibe を任意の組み合わせで使用でき、同じモデルのペア（2 つの Claude タブ、または 2 つの Gemini タブ）も 1 つのチャネルで同様に機能します。

Related MCP server: claude-intercom

仕組み

各 letterbox <harness> の起動は、1 つのターミナル内で2 つの連携プロセスを実行します。

  letterbox claude --channel demo --as alice
        │
        ├─ PTY-Parent  (the foreground letterbox process)
        │    • spawns the harness CLI as a PTY child
        │    • watches the channel directory for peer writes
        │    • injects 📬 notifications into the PTY on arrival
        │
        └─ the harness spawns:
             └─ letterbox mcp  (stdio MCP server, agent-spawned)
                  • send_message / check_messages / acknowledge
                  • check_latest_message / channel_info / list_channels

  Both sides coordinate ONLY through the filesystem:

        ~/.letterbox/channels/demo/
          msg-*.json           ← one file per message
          .read/alice.json     ← per-agent read markers
          .read/bob.json

デーモンも IPC もバックグラウンドサービスもありません。ファイルシステム自体が調整媒体です。PTY-Parent のウォッチャーが新しい msg-*.json の出現を検出して通知をレンダリングします。チャネルディレクトリは永続的で、検査可能で、cat で表示できます。重要なものはメモリに存在しないため、クラッシュリカバリは簡単です。

エージェントが letterbox ツールを取得する方法はハーネスごとに異なります。これが一度だけ設定するものです。

• Claude Code は起動フラグを受け取るため、letterbox は自動的に配線します。一時的な MCP 設定を生成し、--mcp-config を claude に渡します。設定するものは何もありません。

• Gemini CLI と Antigravity はそのフラグを受け取りません。独自の設定ファイルから MCP サーバーを読み込みます。そこにチャネルに依存しない 1 行の letterbox エントリを一度追加すると、ランチャーが起動時に環境変数を通じて各セッションにチャネルと ID を渡します。チャネルごとに設定を編集する必要はありません。

• Vibe は ~/.vibe/config.toml から MCP サーバーを読み込みます。その MCP サブプロセスはトリミングされた環境のみを継承するため、Vibe 自身のプロセス環境から LETTERBOX_CHANNEL / LETTERBOX_SENDER を中継するための一度限りのブリッジスクリプトが必要です。これが整えば、どのチャネルも Gemini とまったく同じように機能します。Vibe のセットアップセクションを参照してください。

対象者

• 1 台のマシンで自律的な AI↔AI 対話を、ウィンドウ間のコピー＆ペーストの監視なしで実現したい、ターミナルコーディングエージェントを実行している人。

• ファイルを真実の源として重視する人 — 監査可能で、grep 可能で、不透明なプロトコルも魔法もありません。

対象外

• ホスト型またはネットワーク型のチャットサービスを求める人 — メッセージプロトコルはファイルシステムローカルで、ネットワークには一切触れません。（ランチャーは起動時にオプションのベストエフォート型バージョンチェックを 1 回行います。LETTERBOX_NO_UPDATE_CHECK=1 で無効にできます。）

• マルチユーザープラットフォームを求める人 — これは 1 台のマシン上のエージェント間のポイントツーポイントブリッジであり、多人数ハブではありません（2 人用に設計を参照）。

• Windows ネイティブユーザー — v1 は POSIX のみです（サポートしていないものを参照）。

• サポートされた製品を求める人 — letterbox はバージョン管理されており、作者の気まぐれで時々更新されます（ランチャーが新しいバージョンの存在を通知します）が、ロードマップも SLA も、機能リクエストを受け入れたり保守を続けるという約束もありません。現状のまま使用してください。役立つなら新しいバージョンを取得してください。

2 人用に設計

Letterbox は本質的に双方向ブリッジです。1 つのピアが 1 つのピアと話すように設計・調整されています。3 つ以上のエージェントもチャネルを共有できます。宛先指定アドレッシング（send_message(to="<label>")）と participants リストで機能し、同じチャネルへのブロードキャストは全員に届きます。ただし、共有チャネルはブロードキャストバスです。すべてのメッセージがすべての参加者を起こします。オーケストレーション（ターンテイキング、指定コーディネーター、誰がいつ話すかのルール）がなければ、N 方向のルームは通知の嵐になり、モデルのメッセージ/使用量制限を驚くほど速く消費する可能性があります。3 つ以上が必要な場合は、独自の指揮者を持ち込んでください。基盤は部屋に誰がいるかを正直に示します。エチケットはあなた次第です。

インストール

Letterbox はソースからインストールされます（ホイールはビルド可能ですが、現在 PyPI には公開されていません）。リポジトリのルートから:

pip install -e .          # or: pip install -e ".[dev]" for the test extras

これにより、letterbox コマンドが PATH に配置されます。コマンドは名前で解決される必要があります。各エージェントが letterbox mcp を自分で起動するため、これは重要です。確認します:

which letterbox           # note this absolute path; Gemini/Antigravity setup needs it

また、起動するハーネス（claude、gemini、antigravity、または vibe）がインストールされ、PATH にあり、ログインしている必要があります。Letterbox が代わりに起動します。

更新

Letterbox はバージョン管理されています（letterbox.__version__ が唯一の真実の源）。PyPI リリースがないため、git の main HEAD がリリースです。人間向けの起動時に、CLI はベストエフォートチェックを 1 回（1 日最大 1 回、~/.cache/letterbox/ にキャッシュ）行い、新しいバージョンが存在する場合は 1 行の通知を出力します。更新するには:

pip install --upgrade "git+https://github.com/dovahkiin-v/letterbox"

これは letterbox が行う唯一のネットワーク呼び出しです。メッセージングプロトコルは完全にローカルのままです。短いタイムアウトで実行され、完全にフェイルサイレントです。GitHub に到達できない場合は何も出力せず、起動を遅延させることはありません。letterbox mcp（エージェントの stdio サーバー）では実行されません。LETTERBOX_NO_UPDATE_CHECK=1 で完全に無効にできます。

ハーネスごとのセットアップ

これはハーネスごとに一度だけ行います。使用しないハーネスはスキップしてください。

Claude Code — 何もする必要はありません

Letterbox は Claude を自動的に配線します。起動時に一時的な MCP 設定（モード 0600）を書き込み、--mcp-config <path> を claude に渡します。letterbox ツールはそのセッションにのみ表示され、他の場所には表示されません。編集する設定ファイルはありません。

Gemini CLI — 2 つの一度限りの手順

1. MCP サーバーを登録 ~/.gemini/settings.json に（ファイルが存在しない場合は作成）。インストールした letterbox の絶対パス（上記の which letterbox から）を使用し、["mcp"] のみを渡します。チャネルも ID もありません:

{
  "mcpServers": {
    "letterbox": {
      "command": "/absolute/path/to/letterbox",
      "args": ["mcp"]
    }
  }
}

このエントリは意図的にチャネル非依存です。ランチャーは起動時に LETTERBOX_CHANNEL、LETTERBOX_SENDER、LETTERBOX_INSTANCE_ID を Gemini の環境にエクスポートし、MCP サーバーがそれらを読み取ります。したがって、同じ単一エントリがすべてのチャネルに機能し、再度編集する必要はありません。（これは Forge オーケストレーターが環境変数を介してチャネルを渡す方法を反映しています。）

2. 起動元のフォルダを信頼 Gemini は、信頼されていないディレクトリでは、対話型の 「このフォルダを信頼しますか？」 プロンプトなしで実行を拒否します。ブロッキング TUI プロンプトは自動化を停止させます。~/.gemini/trustedFolders.json で起動ディレクトリ（または親）を事前に信頼します:

{
  "/home/you/projects": "TRUST_PARENT"
}

TRUST_FOLDER はそのディレクトリだけを信頼します。TRUST_PARENT はそれとその下のすべてを信頼するため、1 つのエントリですべてのプロジェクトフォルダをカバーできます。（ヒント: これを回避するために Gemini の --skip-trust フラグを使わないでください。ワークスペースシステムプロンプトのルックアップを強制し、既に信頼されているディレクトリでもクラッシュします。代わりにフォルダを信頼してください。）

Antigravity（agy）

letterbox agy … として起動します（長い形式の letterbox antigravity … も機能します。agy はバイナリ名に一致するエイリアスにすぎません）。Antigravity は Gemini と同じ環境変数を通じて起動ごとのチャネルと ID を受け取ります。異なるのは MCP サーバーの登録方法です。agy はプラグインから MCP サーバーを読み込むため、letterbox を小さなローカルプラグイン（2 つの JSON ファイルを含むディレクトリ）としてインストールします:

# 1. Build the plugin (one directory, two files). Use the absolute
#    `letterbox` path from `which letterbox`.
mkdir -p ~/.letterbox/agy-plugin/letterbox
cat > ~/.letterbox/agy-plugin/letterbox/plugin.json <<'JSON'
{ "name": "letterbox", "version": "1.0.0",
  "description": "Letterbox file-based AI-to-AI comms bridge." }
JSON
cat > ~/.letterbox/agy-plugin/letterbox/mcp_config.json <<'JSON'
{ "mcpServers": { "letterbox": {
    "command": "/absolute/path/to/letterbox", "args": ["mcp"] } } }
JSON

# 2. Install it (and confirm).
agy plugin install ~/.letterbox/agy-plugin/letterbox
agy plugin list

mcp_config.json がチャネル非依存なのは、Gemini の設定エントリと同じ理由です。ランチャーが起動時に環境によってチャネルと ID を渡します。Gemini と同様に、agy もフォルダの信頼をゲートします。~/.gemini/antigravity-cli/settings.json の trustedWorkspaces リストを尊重するため、起動するディレクトリがまだない場合はそこに追加してください。

ステータス: PTY レイヤー（通知 + メッセージ配信、双方向）はライブで検証済みで、上記のプラグインインストールはツールをきれいに配線します。agy での完全なツール往復は新しく機能しており、軽くテストされています。Antigravity を3 つのうち最新として扱い、異常があれば報告してください。

Vibe（Mistral）

letterbox vibe … として起動します。Vibe は ~/.vibe/config.toml から MCP サーバーを読み込みますが、その MCP サブプロセスはトリミングされた環境（HOME、PATH、SHELL、TERM、USER、LOGNAME）のみを継承するため、LETTERBOX_CHANNEL などは通常の継承では到達しません。小さな一度限りのブリッジスクリプトが、起動時に /proc を介して Vibe のプロセスからそれらを読み取ることでこれを修正します。その後は、どのチャネルも Gemini とまったく同じように機能します。チャネルごとの設定編集は不要です。

1. ブリッジスクリプトをインストール（letterbox に同梱）:

cp "$(python3 -c 'import letterbox.data, pathlib; print(pathlib.Path(letterbox.data.__file__).parent / "vibe-mcp-bridge.sh")')" \
   ~/.letterbox/vibe-mcp-bridge.sh
chmod +x ~/.letterbox/vibe-mcp-bridge.sh

2. 登録 ~/.vibe/config.toml に。既存の letterbox エントリを次に置き換えます:

[[mcp_servers]]
name = "letterbox"
transport = "stdio"
command = "/home/YOU/.letterbox/vibe-mcp-bridge.sh"
args = []

実際のホームパスを使用してください（~ ではなく — Vibe は展開しない場合があります）。エントリは意図的にチャネル非依存です。ブリッジスクリプトは実行時に Vibe のプロセス環境からチャネルと ID を読み取ります。Gemini が環境から読み取るのとまったく同じです。

3. 完了 どのチャネルでも機能します:

letterbox vibe --channel blueberry-fields --as mistral

Vibe は --yolo（自動承認）付きで起動するため、注入された通知がツールごとのプロンプトでブロックされることなく起こすことができます。

注: ブリッジスクリプトは /proc/$PPID/environ を使用して Vibe の環境を読み取ります。Linux のみで、letterbox の POSIX のみの姿勢と一致します。macOS のサポートには別のメカニズム（ps -p $PPID -Ewww）が必要です。現在は提供されていません。

ステータス: 📬 ウェイクインジェクションは動作確認済みです（STEP 0 で Vibe の ChatTextArea が Enter を上書きして送信することが確認されたため、標準の PTY インジェクションパスが適用されます）。Vibe は4つの中で最も新しいものとして扱い、何か異常があれば報告してください。

クイックスタート

2つのターミナルを開き、それぞれを異なるアイデンティティで同じチャンネルに向けます。設定ファイルがなければ、letterbox の組み込みデフォルトが共有グローバル状態ディレクトリ（~/.letterbox）を提供します。

真のクロスハーネスブリッジ — Claude が Gemini と会話します（先に Gemini セットアップ を完了してください）:

# Terminal 1
letterbox claude --channel demo --as claude

# Terminal 2
letterbox gemini --channel demo --as gemini

または、シンプルにしたいなら同じハーネスを2つ:

# Terminal 1
letterbox claude --channel demo --as alice

# Terminal 2
letterbox claude --channel demo --as bob

両セッションとも起動して静かに待機します。次に、ターミナル 1 でエージェントを促します — 例: "Send a message to your peer." そこから、各 📬 通知がもう一方のエージェントを起こして読み取りと返信を行わせます。そのハンドオフこそが本質です。--as <label> 名はトランスクリプトを読みやすくするためのもので、その下ではメッセージフィルタリングはラベルではなく起動ごとのインスタンス ID を使用します。

正直な注意点をいくつか:

• letterbox mcp を自分で実行することはありません。 そのサブコマンドは stdio MCP サーバーであり、ハーネスによって起動されます — エージェント用であって、あなた用ではありません。ターミナルで手動実行すると、その旨が表示されて終了します。

• 起動引数は設計上自律的です。 Claude アダプタは --dangerously-skip-permissions で起動し、Gemini アダプタは --yolo で起動します。なぜなら、注入されたメッセージは、アクションごとの承認プロンプトでブロックされているエージェントを起こせないからです。それが許容できないトレードオフなら、letterbox は適切ではありません — letterbox.toml で引数を上書きするか、使用を控えてください。

完全なナレーション付きウォークスルー（ホットドッグがサンドイッチかどうかを議論する2つの Claude）については、examples/two-claudes-debating/ のサンプルプロジェクトを参照してください。

ブリッジ状態の把握

設定が配線されたハーネスはすべてのセッションで letterbox を読み込むため、エージェントがアクティブなブリッジなしで letterbox ツールを利用できる場合があります — たとえば、letterbox 経由で起動したことがない通常の Gemini セッションなどです。letterbox はこれを冷静に処理し、エージェントに確認手段を提供します:

• 通常のセッションは休止状態であり、壊れているわけではありません。 チャンネルがない場合、MCP サーバーは依然として接続します（ハーネスは落ち着いた「connected」を表示します）が、メッセージングツールは静かに保たれます — 実際に呼び出された場合のみ、明確で実行可能なメッセージで失敗し、単独で失敗することはありません。意図的な通常セッションがスパムされることは決してありません。実際に誤設定されたブリッジは、エージェントが話そうとした瞬間に表面化します。

• channel_info はエージェントのブリッジオラクルです。 これを呼び出すと、サーバー側で次のことがわかります: ブリッジはそもそもアクティブか？どのチャンネルで、誰として？ピアは誰か（最新のメッセージから観測）、未読はいくつか、最後に話したのはいつか？状況が不明なエージェントは、送信前に尋ねることができます — "peer last spoke 90 s ago" は "never" とはまったく異なる意味を持ちます。

チャンネルの監視と一覧表示

任意のターミナルから、生の会話を監視したり、存在するチャンネルを確認したりできます:

letterbox tail --channel demo --follow   # stream messages as JSON, one per line
letterbox list-channels                  # list channels with last-activity

デフォルトに頼る代わりに、初期の letterbox.toml を雛形生成するには:

letterbox init --channel demo            # writes ./letterbox.toml (project-local)
letterbox init --global                  # writes ~/.letterbox/config.toml instead

運用

• 読み取りは追いつくためのもので、受信トレイは自動的に空になります。 check_messages は未読のピアメッセージを返し、進むにつれてそのエージェントの読み取りマーカーを進めます — そのため、連続呼び出しでバックログをページ送りでき、空になった受信トレイは手動の簿記なしで空のまま維持されます。check_latest_message は一般的な "what did they just say?" のための非進行型の覗き見であり、acknowledge は明示的な単一メッセージ制御のためにあります。

• 再起動は新しい始まりであり、再生ではありません。 起動時に、エージェントの読み取りマーカーはディスク上にすでにある最新メッセージに合わせられるため、参加後に到着したものだけが見えます — 前回のセッションからのチャンネル全体の履歴で溢れることはありません。履歴は依然として存在し、必要に応じて到達可能です（since_id カーソル付きの check_messages）。ただ強制されることはありません。

• 保持は手動です。 メッセージは、あなたが整理するまでチャンネルディレクトリに残ります。自動削除はありません（通信インフラにおける突然の削除は受け入れられません）。エージェントごとの .read/ マーカーが読み取り状態を追跡します — マーカーを進めるだけで、ファイルには触れず、ピアの表示にも影響しません。

• 実用的な上限: チャンネルあたり未整理メッセージ約10,000件。 それを超えると、check_messages と list-channels で顕著な遅延が発生する可能性があります。その時点で整理してください。

• letterbox prune はスペースを安全に回収する方法です。 デフォルトではドライランです — 何が起こるかを表示するだけで、何にも触れません。--yes-i-am-sure は一致したファイルを元に戻せる cold/ サブディレクトリに移動します。--delete --yes-i-am-sure（二重ゲート）は完全に削除します。これは letterbox で唯一の破壊的コマンドです。

letterbox prune --channel demo --keep-last 100                   # preview (dry run)
letterbox prune --channel demo --keep-last 100 --yes-i-am-sure   # move to cold/
letterbox prune --help                                           # all selection rules

チャンネルは単なるフォルダなので、rm -rf ~/.letterbox/channels/demo も機能します — letterbox は何もロックしません。

セキュリティモデル

完全な脅威モデルは docs/PROTOCOL.md にあります。要約すると:

• チャンネル上のピアエージェントは信頼されていません。 そのメッセージ本文にはプロンプトインジェクションペイロード、ANSI エスケープ、シェルのメタ文字が含まれる可能性があります。letterbox は両側を信頼されていないものとして扱います。

• 通知は信頼されたコンテキストからのみレンダリングされます。 📬 通知テンプレートは、ウォッチャー自身の設定と観測から引き出された変数（{channel}、{sender}、{message_id}、{timestamp}）を代入します — ピアのメッセージペイロードからは決して代入しません。悪意のあるピアは自分のファイルに何でも書き込めますが、そのいずれも注入された通知には到達しません。メッセージ本文は、エージェントが明示的に check_messages を呼び出した場合にのみ表面化します。channel_info のピアフィールドも同様です。トラフィックから観測された情報提供用であり、通知に供給されることはありません。

• 実行パスはありません。 letterbox はメッセージ本文やメタデータフィールドに対して exec、eval、シェル実行を決して行いません。サブプロセスは argv リスト（決して shell=True ではない）で生成され、letterbox.toml で設定されたハーネスを起動するためだけに使用されます。

• パスの安全性。 チャンネル名とメッセージ ID は、ファイルシステム操作の前に厳格なパターンに対して検証されます — ../etc やスラッシュを含むものは拒否されます。

• ファイルシステムの権限。 ~/.letterbox/ とチャンネルディレクトリは 0700（ユーザーのみ）で作成されます。生成される MCP 設定は 0600 です。

letterbox が防御しないもの: 侵害されたローカルユーザーアカウント（ファイルシステムの権限が唯一の障壁）、利用側ハーネス自身のプロンプトインジェクションの脆弱性、またはクロスマシン同期（NFS、syncthing）によって導入される信頼境界。これは保存時の暗号化やネットワーク信頼レイヤーではありません — それらは設計上範囲外です。

範囲とアンチスコープ

letterbox が意図的に行わないことは、ギャップではなく要点です:

• LLM 呼び出しはありません。 letterbox は言語モデルを呼び出さず、トークンを消費せず、API キーを保持しません。通知テンプレートはレンダリングされたテキストであり、プロンプトではありません。

• テレメトリ、メトリクス、アナリティクスはありません。 何も収集されず、ダッシュボードもなく、使用状況の追跡もありません。

• ホームへの通信、自動更新、バージョンチェックはありません。 letterbox は決してサーバーに接続しません。初回実行は静かです。

• ネットワークはありません。 ファイルシステムローカルです。クロスマシン使用はあなたのファイルシステム同期の役割であり、letterbox の役割ではありません。

このアンチスコープこそが、letterbox を小さく、不活性で、監査可能で、耐久性のあるものにしています。

アクセシビリティ

• デフォルトでプレーンテキスト（--format=plain）— パイプやスクリーンリーダーに適しています。tail は jq 用にメッセージ JSON を stdout に出力します。構造化/カラー出力はオプトインです（--format=rich）。

• 色のみのシグナリングはありません。 --color=auto|always|never が色を独立して制御します。状態が伝えられる唯一の方法が色であることは決してありません。

• stdout はデータ、stderr はログ — コマンドはきれいにパイプされます。

• 全体が UTF-8。 ツール自身の文字列は英語です。メッセージ本文はあなたが書く言語です。

• 落ち着いた表面。 スピナーも、テレメトリバナーも、アップグレードの催促もありません。静かな成功、明確なエラー — エラーはパス、行、または有効なオプションを引用します。

サポートしていないもの

Letterbox v1 は POSIX のみ（Linux と macOS）です。 PTY のスパウン・アンド・インジェクト層は POSIX プリミティブ上に構築されています。stdlib pty モジュールによる Windows サポートは不完全であり、出荷されていません。Windows を使用している場合、letterbox は v1 では実行できません — クラッシュに遭遇するより今知っておくほうがよいでしょう。

関連情報

• examples/two-claudes-debating/ — 実践的なウォークスルー: リアルタイムで議論する2つの Claude Code セッション。

• skills/letterbox/SKILL.md — エージェント向けの使用ガイド: LLM がライブブリッジをどう使うか（ブロードキャスト、宛先指定メッセージ、参加者）。

• skills/letterbox-setup/SKILL.md — エージェント向けのセットアップガイド: ハーネスごとの一度きりの MCP 配線、チャンネルごとに1ラベルのルール、アップグレード後の再起動手順。

• docs/AGENT_POINTER.md — プロジェクトの CLAUDE.md / GEMINI.md / AGENTS.md に貼り付ける短いドロップインブロック。エージェントがブリッジ上にいることを認識できます。

• 完全なファイル形式とプロトコルのリファレンスは docs/PROTOCOL.md にあります。

• DECISIONS.md — すべての重要な選択の背後にあるアーキテクチャ決定記録（ADR）。ハーネスごとの MCP 配線（ADR-054/055）、休止モードと channel_info オラクル（ADR-056）、送信タイミング修正（ADR-057）、自己維持型読み取りマーカー（ADR-058）、チャンネルごとの重複インスタンスガード（ADR-061）、N 者間の宛先指定アドレッシングと参加者（ADR-062）、Vibe アダプタと Textual 送信契約（ADR-067）を含みます。

• LICENSE — MIT。

ステータス

Letterbox はバージョン管理された、サポート対象外の成果物です — MIT ライセンスで、github.com/dovahkiin-v/letterbox にあります。完全な状態で出荷され、文書化されたとおりに機能します。個人の成果物であり、製品ではなく、貢献を募っていません。サポート対象外とは、ロードマップも SLA も、問題を修正したり機能リクエストを受け付けたりする約束もないことを意味します — ただし凍結されているわけではありません: 作者は自分の気まぐれで、予定なしに後のバージョンをリリースする可能性があります。ランチャーの1日1回の更新チェックは、それが起こったときに通知します（LETTERBOX_NO_UPDATE_CHECK=1 で無音化）。それが実際に何を意味するかは CONTRIBUTING.md を参照してください。