rigs

rigs：OpenRig への入り口

OpenRig は、コーディングエージェント（Claude Code、Codex など）を tmux で並行して動かすチームを実行します。ローカルデーモンがタスク、メッセージ、状態を保持するため、再起動後もチームは作業を続けられます。このスキルを使うと、OpenRig をインストールし、ユーザーが望む作業に取り組むチームを動かし、ここからそのチームと連携する方法を確認できます。

目標は、インストールだけでなく、チームにユーザーの作業を任せることです。 手順に沿って進め、ユーザーから求められた場合に限り、途中で止めてください。ユーザーが作りたいものを伝えたら、自分で作るのではなく、OpenRig のオペレーター（ステップ 2）に伝えてください。

実行する前に、これから何を実行するのか、なぜ実行するのかをユーザーに伝えてください。ユーザーの同意なしにシステムパッケージをインストールしたり、ユーザーのマシンを変更したりしてはいけません。また、チームを開始する操作（rig up を含む）も、何が開始されるかについてユーザーの同意を得てから行ってください。同じ起動についてすでに同意を得ている場合は、再度尋ねる必要はありません。OpenRig とチームの起動ではファイルが書き込まれます。Codex のフックと設定は ~/.codex/config.toml に、Claude Code のワークスペースの信頼設定は ~/.claude.json に、検出用スキルは ~/.claude/skills と ~/.agents/skills に書き込まれます。また、リポジトリには管理対象のガイダンスが AGENTS.md または CLAUDE.md に、アクティビティフックが .claude/settings.local.json に書き込まれます。そのプロジェクトに既存のものがない場合は、同じ場所にステータス行も書き込まれます。さらに、チームのスキルとプラグインも書き込まれます。権限ポリシー、シートごとの選択、または Codex の場合は名前付きプロファイルが適用されない限り、カーネル自身のシートは運用上のデフォルト設定で動作します。Codex は -s danger-full-access -a never で、Claude Code はファイルツール、ウェブ取得、ホームフォルダー内の読み取りを含む運用コマンドが、確認なしで許可されます。OpenRig を起動する前に、そのことを伝えてください（変更内容の全一覧）。

変更をプロジェクト内に留めたい場合： セットアップまたは最初のデーモン／カーネルの起動より前に、選択された Codex 設定パス（CODEX_HOME/config.toml、デフォルトは ~/.codex/config.toml）を明示し、独立した書き込みについて説明してください。セットアップでは ~/.tmux.conf が追加されます。Codex シートの起動では、ワークスペースの信頼設定と、宣言された設定フラグメント（MCP を含む）が追加されます。セットアップを省略した場合や runtime.codex.hooks_enabled が false の場合も同様です。この設定が制御するのはフックであり、すべての設定書き込みではありません。これらの設定は、同じ Codex ホームを使用する他のセッションにも影響する場合があります。これらの書き込みについてすでに同意を得ている場合は、その同意を再利用してください。「プロジェクト内だけ」という明示的な要望は、これらの書き込みへの同意にはなりません。ユーザーが同意しない場合は、同じパスで起動してはいけません。また、同意の代わりに後から書き込みを削除してもいけません。セットアップにはプロジェクト限定モードがないことを説明してください。Git のワークツリーやプロジェクトの .codex/config.toml では、これらの書き込み先は変更されません。既存の別個の CODEX_HOME を使えば、Codex の設定、ログイン、セッション状態をまとめて分離できます。ただし、独自に動作するサインインが必要であり、~/.tmux.conf の保存先は移動しません。ユーザーのスコープに関する制約をオペレーターに伝えてください。

Codex の個別承認： インストール前に、チームの権限とは別に、セットアップ中やその後の作業で、読み取り操作であっても繰り返し確認される場合があることを説明してください。それぞれの要求が分かりやすいよう、個別の通常のコマンドを使ってください。以下に示す任意の 6 コマンドの承認提案は引き続き利用できます。確認を避けるために、一般的なネットワークアクセスを有効にしたり、ほかの権限設定を拡大したりしてはいけません。

ユーザー自身のターミナルで実行するファイルやコマンドを案内するときは、ユーザー側に実在するパスを使ってください。サンドボックス化されたエージェントが /tmp に書き込んだファイルは、ユーザーのターミナルから存在を確認できない場合があります（Codex で確認されています）。そのため、ユーザーが必要とするファイルはプロジェクトまたはホームフォルダーに置き、そのパスを明示してください。

1. OpenRig がインストールされていない場合は、インストールします

• まず確認します： rig --version。バージョンが表示されたら、ステップ 2 に進みます。
• 必要なもの： macOS または Linux、Node.js 22 または 24、tmux、Claude Code または Codex へのサインイン。不足しているものだけを確認します：node --version、tmux -V、claude auth status または codex login status。
• ネットワークが必要な確認（gh auth status、レジストリやその他の取得処理）は、Codex のデフォルト環境のようにネットワークアクセスのないサンドボックスでは、誤って失敗する場合があります。再度サインインするよう伝えたり、何かを修正したりする前に、そのコマンドをネットワークアクセスがある状態で再実行します。
• インストール： npm install -g @openrig/cli を実行し、続いて rig setup --providers codex（または claude、もしくは both：本人が使うハーネス）を実行します。セットアップでは Node、tmux、サインイン状態を確認します。いずれかが不足している場合、tmux（Homebrew がある場合は Homebrew を使用）または選択したハーネス（npm を使用）をインストールし、本人が辞退しない限り（--no-herdr）OpenRig ビュー用の Herdr をインストールし、~/.tmux.conf に OpenRig のブロックを追加するので、先にこれらすべてを伝えます。デーモンは起動しません。その後、rig doctor を実行します。
• その後、ステップ 2 に進みます： インストール済みであることを伝え、何に取り組みたいか、どのリポジトリで作業するかを尋ねます。単に「OpenRig をインストールして」と言われた場合も、ここまで行います。チームを開始しないよう言われた場合に限り、ここで止めます。
• 失敗した場合： rig context get help は、インストール済みバージョンのヘルプガイドです。rig 自体が動かない場合は、https://www.openrig.dev/help/agents を使います。スタートガイド：https://openrig.dev/docs/getting-started

2. OpenRig を開き、オペレーターに目標を伝えます

• OpenRig を起動します： rig daemon status を実行し、起動していない場合は rig daemon start を実行します。rig preflight と rig doctor は起動しません。起動すると、OpenRig 独自のチームであるカーネルも起動します。カーネルのオペレーターが本人のチームをセットアップします。そのまま使います。

• 本人が Codex を使う場合： OpenRig の起動後、このステップの最後にある「Codex：一度だけ、OpenRig 起動後に行う案内」に沿って、一度だけ案内します。

• OpenRig を見せて、引き継ぎます： OpenRig の起動後、本人のために OpenRig TUI とオペレーターを開きます。開くことを伝えてから、デーモンのデスクトップで rig terminal open saved:kernel --window を実行します。これは、OpenRig のインストールまたは起動後の次のステップであり、本人がエージェントや OpenRig を使いたいときにいつでも戻る方法です。尋ねられるのを待ったり、特定の言葉を言われるのを待ったりしません。今は開かないと言われた場合は、後で使えるようにこのコマンドを伝えます。このコマンドは自身でビューを開き、Herdr がインストールされていれば Herdr を、そうでなければ通常の tmux を使います。

  • Herdr 内の場合（Herdr のペインで実行している場合）：本人の Herdr を openrig kernel スペースに切り替えます。起動中のスペースがあれば再利用します。新しいウィンドウは開かず、macOS のプロンプトも表示されません。本人のスペースはサイドバーに残ります。
  • Rex 内の場合（Rex ブロック内、またはその中で起動した tmux 内で実行している場合）：同じ Rex サーバー上に openrig kernel セッションを開き、Rex アプリにそのセッションへ切り替えるよう依頼します。新しいウィンドウは開かず、macOS のプロンプトも表示されません。再度開くたびに、番号付きのセッションが追加されます。
  • Terminal または Ghostty の場合： 本人のウィンドウと同じサイズの新しいタブまたはウィンドウを開きます。
  • Mac の Claude Desktop、iTerm、または VS Code から実行する場合： 対応していれば新しい Ghostty ウィンドウを開き、そうでなければ Terminal を開きます。この場合に限り、実行前に、macOS からそのアプリの制御を求められたら 「許可」で問題ありません と伝えます。echo $TERM_PROGRAM $__CFBundleIdentifier $REX_BLOCK を実行すると、どこで実行しているかが分かります。herdr、rex、Apple_Terminal、ghostty、または com.apple.Terminal、com.mitchellh.ghostty、あるいは REX_BLOCK の値を伴う tmux の場合、macOS のプロンプトは表示されないため、言及しません。それ以外（iTerm、VS Code）の tmux ではプロンプトが表示される場合があるため、先に「許可」で問題ないと伝えます。
  • レイアウト： 120 列未満ではオペレーターが最初のページ全体を使います。120 列以上では、ダッシュボードとオペレーターが同じページを共有します。アドバイザーは専用のタブまたは tmux ウィンドウを使います。 次に、そのウィンドウが開いた場所と、オペレーターが希望するものを構築する準備ができていることを、1〜2文で伝えてください。エージェントやステータスは列挙しないでください（TUIに表示されます）。また、入力するコマンドを提案しないでください。 現在のターミナルはそのままにしてください。OpenRigのメモにビューを確認できなかったとある場合は、その旨をはっきり伝えてください。すでに開いている場合は、別のウィンドウを開かず、そこへ案内してください。ウィンドウを開けない場合に限り、rig tui --shared がダッシュボード専用の代替手段です。失敗したことを説明し、選んだ代替手段を使えるよう支援してください。Herdrが見えるのは、その人が確認できるターミナルだけです。共有TUIを:terminalsに切り替えても、ターミナルは開きません。Noやヘッドレス／SSHでの利用は、適切なバックグラウンドでの結果です。プロバイダーのみを指定する--provider herdr、--provider cmux、または--provider rexは、すでに起動しているプロバイダー用であり、最初のデスクトップウィンドウを開くためのものではありません。また、これらを指定して開くたびに、新しいワークスペースが追加されます。

• ウィンドウを開けない場合、またはヘッドレスSSH経由の場合： 目に見えるターミナルは開かなかったことをはっきり伝え、デーモンが動作しているホストで新しいターミナルウィンドウまたはタブを開くよう依頼してください。SSH経由の場合は、既知のアカウントでそのホストに新しいSSHセッションを開くよう伝えてください。HTTPデーモンのアドレスしかわからない場合は、詳細を推測せず、SSH接続の詳細を尋ねてください。その後、完全なコマンドを1つ提示してください。

  • OpenRigが出力したコマンド： rig terminal open saved:kernel --windowでウィンドウを開けない場合、理由が示され、最後にrun:とコマンドが出力されます（--jsonではerrorフィールド）。そのコマンドには、インストール済みのherdrバイナリとデーモンのソケット、または接続する会話がすでに指定されています。独自に作成せず、そのまま伝えてください。Herdrの起動後にビューを配置するようメモに指示がある場合は、起動後に自分でrig terminal openを実行してください。
  • コマンドが出力されなかった場合： rig ps --nodes --rig kernel --json --fields logicalId,canonicalSessionName,tmuxAttachCommandからoperator.agentを探し、そのtmuxAttachCommandを記載どおりに使用して、オペレーターの会話に接続するコマンドを提示してください。名前を推測してはいけません。コマンドの先頭にはenv -u TMUXを付けてください。デフォルト以外のtmuxサーバーが使用されている場合、そのコマンドにはデーモンのtmuxサーバーが指定されています。

  それ以外の失敗については、rig context get reference/getting-started.md#open-the-kernel-conversationsにある「What can interrupt installation and the OpenRig view」の表に、理由と次に行うことが記載されています。

• 最初の送信前に、このセッションへの参加を提案する： このセッションにまだ参加していない場合は、オペレーターに「unknown sender」ではなく名前付きのチームメイトとして認識されるよう、通常のシェルからOpenRigに参加することを勧めてください。tmux内では、以下の影響を短く説明したうえで、参加は任意であることを伝えてください。その後、参加するかどうかを尋ねてください。

  • 私が名前付きのチームメンバーとして参加し、メッセージに自分の名前が表示されます。
  • 通常のシェルでは、参加してもプロジェクトや個人設定にファイルは書き込まれません。
  • 0.6.11のtmux内では、私の送信者名と返信先アドレスは、既存のtmuxセッション名になります。0のような数字の場合も同じです。rig attach --selfでそのアドレスを取得でき、rig whoamiで確認できます。--display-nameを指定してもアドレスは変わりません。
  • tmux内では、ほかのエージェントがこのウィンドウに入力できます。また、チームを停止すると（rig down）、このtmuxセッションも閉じます（どちらもソースコードから確認したもので、手動ではテストしていません）。トランスクリプトの記録、およびClaude Codeでステータス行のために.openrig/context-collector.cjsと.claude/settings.local.jsonを書き込む動作は、0.6.11で手動テスト済みです。既存のカスタムステータス行を保持したまま.claude/settings.local.jsonを更新する動作は、ソースコードから確認したものです。
  • 通常のシェルでは、ほかのエージェントはこのウィンドウに入力できないため、タスクキューを通じて返信します。チームを停止しても、このセッションは実行されたままです。 同意した場合にのみ接続します。断られた場合は、オペレーターへの引き継ぎを続けます。最初の接続には、カーネルの rig ID（rig ps --json の kernel 行にある rigId）と、その operator ポッドを使います。 rig attach --self --rig <rigId> --pod operator --member person-agent --runtime <claude-code|codex> --print-env。 --node <logicalId> を指定すると、既存のシートにバインドされます。一度だけ接続し、出力される変数 （OPENRIG_NODE_ID と OPENRIG_SESSION_NAME）を保持します。各コマンドは新しいシェルで実行される場合があるため、以降のすべての rig コマンドの前にこれらを設定してください。rig whoami --json で確認し、その後の識別情報や状態の確認には rig attach --json の出力ではなく、これまたは rig seat status を使います。OPENRIG_ACTIVITY_* の値は表示しないでください。これらは認証情報です。 断られた場合でも、誰からのメッセージかが分かる必要があるメッセージは、送信元を明記したキュー項目として送れます。 rig queue create --source <their id>@external --destination <seat> --summary "<one line>" --body-file <file>： シートには、その名前が申告された送信元として表示されます。相手が登録済みであれば、返信できます（rig gateway human list）。 申告された名前は本人の申告にすぎず、シート自身の識別情報ではありません。シートの識別情報だけを基準に動作するチームでは、上記の接続済みシェルを使います。

• オペレーターに目標を伝えます： まだ話に出ていない場合は、何に取り組みたいか、どのリポジトリのどのブランチかを尋ねます。rig ps --nodes --rig kernel --json から operator.agent の行を探し、その canonicalSessionName（論理 ID や推測した名前は使わない）を取得して、次を送信します： rig send <canonicalSessionName> 'This is the agent that installed OpenRig. The person will answer in your pane. Goal: <goal>. Project folder: <absolute path>. Branch: <branch>.' 相手がこちらにとどまる場合は、"The person will answer in your pane" を "The person stays with me; send me your questions and results to relay." に置き換えます。どちらの引き継ぎでも、相手の制約と、許可を断った選択肢があれば伝えます。 または、相手がオペレーターのペインで目標とフォルダーを入力することもできます。後から目標を伝えられた場合も、同じ方法で転送します。オペレーターは、相手のログイン情報に合ったチーム選びを手助けし、表示された計画に相手が同意した場合にのみチームを起動し（rig up）、目標をチームのリードに伝えます。その同意を得る前に、相手のフォルダーで起動すると、そこにある相手自身のエージェントにどのような変更が加わるかを説明します。その内容を質問とともに伝えてください。相手にオペレーターが応答する場所を示し、自分でプロジェクトを作らないでください。

• 相手が以下の Codex の提案を断り、オペレーター経由を明示的に選んだ場合を除き、オペレーターからの質問を伝えます： オペレーターは自身のペインで質問しますが、相手がそのペインを見ていない場合があります。 各ステップを引き継いだ後、rig capture <canonicalSessionName> でオペレーターの画面を読みます。チームを開始するか、どのフォルダーにするか、どの選択肢にするかなど、オペレーターが相手に尋ねたら、オペレーターの言葉どおりにこちらで尋ね、その回答を rig send で送り返すか、オペレーターのペインで回答するよう伝えます。プロンプトやメニューとは異なり、質問があってもシートは停止状態にならないため、バックグラウンドで待たせないでください。

• インストールが完了した状態とは： オペレーターが準備でき、相手がオペレーターと会話している状態です。デーモンが正常に動作しているだけでは完了ではありません。後で話したいとのことなら、その希望に沿い、正確な接続手順を伝え、オペレーターへの引き継ぎはまだ完了していないと説明します。

• 実行中の内容を確認します： rig ps を実行し、続けてチームのエージェントを確認するために rig ps --nodes --rig <rig> を実行します。そのリポジトリで既にチームが稼働している場合は、オペレーターに伝えます。

• 準備ができたと伝える前に確認します： rig ps --nodes --rig <rig> を実行します。エージェントがプロンプトやメニューで停止している場合は、rig capture <seat>@<rig> で内容を読みます。許可を求めるプロンプトには相手が回答します。ほかに待機中の項目があれば、それらも含めて、シート、正確な操作内容、提示された選択肢をそれぞれ一行で相手に示します。選択肢を送る前に、そのシートをもう一度キャプチャします。プロンプトが変わっていたら、回答を使い回さないでください。そのプロンプトに対して相手が選んだ選択肢だけを正確に送信します（プロンプトに数字、文字、Escape キーを送る方法は rig send --help に記載されています）。あるプロンプトへの「はい」は次のプロンプトへの「はい」ではありません。また、相手が選んでいない「今後確認しない」選択肢を選ばないでください。今後表示される特定の種類のプロンプトについて、判断を任せると相手が明確に指示している場合（たとえば「プロジェクト内だけに書き込むプロンプトは承認してください」）、その都度判断してもかまいません。操作の全体を確認し、相手の指示の範囲内であることが明らかな場合にのみ回答し、相手が「はい」と言ったのではなく、その指示に従って回答したことを伝えます。内容が不明確な場合や指示の範囲外の場合は、相手に確認します。コマンド名や、相手のプロジェクトにあるように見えるパスだけでは、操作の対象は分かりません。相手の指示によって許可設定が変更されることはありません。 これ以外の種類のメニューには、画面に表示されているキーで回答するか、相手に尋ねます。追加で何か送信する前に、もう一度キャプチャします。

• 返信： 通常のシェルでは、ほかのエージェントはこのセッションに入力できません。自分宛ての作業は rig queue list --destination <your address> と rig queue show <id> --full で読みます。エージェントの画面は rig capture <seat>@<rig> で確認します。

Codex：OpenRig 起動後に、一度だけ提示する

まず、エージェントはその人の実際の Codex フォルダー（CODEX_HOME、設定されていない場合は ~/.codex）を特定し、正確なパスを提示文に記載します。これにより、プレースホルダーではなく実際のファイルが示されます。

Codex では、OpenRig のコマンドを実行する際に承認が求められます。次の6つのコマンドを、後ろに続く引数も含めて、確認なしで実行できるようにしてもよろしいですか：rig ps、rig capture、rig send、 rig queue、rig status、rig whoami。これらは Codex のサンドボックス外で、このコンピューターで実行するすべての Codex プロジェクトとセッションにおいて実行されます。また、rig send と rig queue は、エージェントにメッセージを送信したり、エージェントのタスク記録を変更したりできます。読み取りだけではありません。ファイルを1つ追加します。/home/you/.codex/rules/openrig.rules（解決済みのパス）です。Codex は起動時にこのファイルを読み込むため、次回の Codex セッションから適用されます。現在のセッションで確認が不要になるわけではありません。個別に承認する設定を維持する場合、ステータスの確認やエージェントの画面の読み取りにも、毎回確認が求められることがあります。準備ができたら、この Codex セッションの権限を変更せずに、オペレーターに直接話しかけることもできます。このルールを取り消すには、ほかのルールを維持したまま、今回追加した OpenRig のルールを削除するよう私に依頼してください。

• いいえ、または回答なし： 何も書き込まず、サンドボックス、ネットワーク、承認の設定を維持します。拒否された場合は、その選択を尊重してください。記憶させた承認を再度提示したり、確認を避けるために一般的なネットワークアクセスを有効にしたりしないでください。準備ができたオペレーターに直接引き継ぐか、個別の承認を続けながらこの場にとどまるかを提案します。すでにどちらかを選んでいる場合は、再度尋ねないでください。
• オペレーターを選んだ場合： 上記の引き継ぎを一度だけ使用し、本人の目標、フォルダー、ブランチ、拒否した権限の選択を引き継いでから、準備ができた会話を案内します。ヘッドレス SSH を介している場合は、上記の接続／アタッチ用コマンドをそのまま使用します。オペレーターと話し始めたら、オペレーターがチームの作業に従って結果をそこで報告します。このインストーラーによる繰り返しのキャプチャ、ステータス、キューのポーリングは停止してください。どちらのセッションも停止、再起動、再設定しないでください。ここにとどまることを希望する場合は、選択された承認の範囲内で引き続き中継します。確認がなくなったとは言わないでください。ルールの提示は任意であり、OpenRig を使用するための条件ではありません。
• はい： エージェントは、OpenRig の既存の権限設定手順（インストール済みの OpenRig スキルにある applying-a-permission-policy）に従って適用します。既存のルールを先に読み、より厳しいルールは維持し、サンドボックスや承認の設定は変更せず、追加した内容を記録します。ファイルが存在しない場合にのみ新しいファイルを作成します。すでに存在する場合、エージェントは何も変更せず、記載内容を伝えます。新しいファイルには、次の2行だけを記載します。

  # Added by OpenRig on the person's yes: these six rig command families run without a prompt. Ask to undo, or delete this file if it holds nothing else.
  prefix_rule(pattern = ["rig", ["ps", "capture", "send", "queue", "status", "whoami"]], decision = "allow", justification = "OpenRig coordination commands the person approved once")
  

• 取り消し（同じスキルでの表現：「この設定で追加した OpenRig コマンドの許可を取り消し、ほかのルールは維持してください」）：エージェントは、追加したと記録した行だけを削除し、ファイル内のほかの内容は維持します。また、ファイルにその行しか残っていない場合に限り、ファイルを削除します。次回の Codex セッションから適用されます。

3. 作業の結果まで追跡する

以下の手順をデフォルトとして使用します。上記の Codex の提案を断り、オペレーター経由で進めることを明示的に選んだ場合に限り、オペレーターがこの後続作業を担当します。

• チームのタスクを見つけます： オペレーターは、キュータスクとしてチームのリードに目標を伝えます。宛先は dev-build@starter、または workshop と factory では orch-lead です（starter と factory では rig specs preview <name> --kind rig で各担当者の役割を確認でき、稼働中のチームでは rig ps --nodes --rig <rig> で確認できます）。rig queue list --destination <seat>@<rig> -a でタスクを探します。
• 結果まで追跡します： 担当が引き継がれたタスクは、まだ完了ではありません。rig queue show <id> --full で引き継ぎ先の担当者がわかります。その担当者の次のタスクは、handedOffFrom がその ID になっているタスクです（rig queue list --destination <seat>@<rig> -a -o json）。エージェントが結果を報告するまで、引き継ぎを一つずつ追跡し、rig capture <seat>@<rig> を使って作業内容を確認します。その後、成果物を読み、依頼者には依頼を送ったことだけでなく、チームが実際に行った内容（ブランチ、コミット、レビュー、または PR の文面）を伝えます。
• チームに追加の作業を依頼します： 変更内容、対象のリポジトリとブランチ、完了の条件、成果（ブランチまたはコミット、レビュー、PR の文面など）が自分に戻ってくることをファイルに記載します。次に rig queue create --source <your name> --destination <seat>@<rig> --summary "<the goal in a sentence>" --body-file <file> を実行し、rig send <seat>@<rig> "task <id> is yours" でエージェントに伝えます。メッセージは情報を伝えるものであり、キュータスクは担当者が責任を持って行う作業です。このセッションでまだチームに参加していない場合、--source には自分の名前を指定します。
• その後、次に何をするか尋ねます。 作業を引き受けられるチームがない場合は、状況を整えるか、依頼者に尋ねます。黙って自分で作業を進めないでください。
• チームと作業するその他の方法： rig send <seat>@<rig> "..." はエージェントのターミナルに入力し、rig capture <seat>@<rig> はエージェントの画面を読み取り、rig ps --nodes --rig <rig> はチームの参加者を表示します。

4. 詳細を確認する

• OpenRig の仕組み： rig context profile world-public --situation fresh。
• できること： rig context get onboarding-width（機能マップ）。
• ライブラリ内のすべて： rig context list。
• 正確な構文： rig <command> --help には、インストール済みバージョンに対応する最新情報が常に表示されます。

ここに書かれている内容と rig <command> --help の内容が食い違う場合は、--help の内容を優先します。