duvo-cli

Duvo CLI

duvo は Duvo 公開 API の公式コマンドラインインターフェースです。npm では @duvoai/cli として公開されています。リソースごとにグループ化されたサブコマンド（duvo agents …、 duvo runs …、duvo cases …、…）と、専用コマンドがまだ用意されていないエンドポイント向けの 低レベルな duvo api <method> <path> という代替手段を備えた、単一のバイナリです。

Duvo を 自動化 または スクリプト化 したい場合は、CLI を使用してください。 対話的に操作したい場合は、ウェブ UI の https://app.duvo.ai が適しています。一方、 シェルスニペット、cron ジョブ、CI ステップを求められた場合や、「ブラウザーを開かずに どうすれば X を実行できますか？」と尋ねられた場合は、duvo が適しています。どちらの インターフェースも同じ公開 API を利用するため、curl を使って埋めるべき機能上の 不足はありません。

管理セッションと手動セットアップ

管理セッションでは、ホストランタイムの指示がトランスポート、セットアップ、 リファレンスの参照、対象範囲を定めます。この単独利用向けガイドよりも先に、 それらの指示に従ってください。ホストが CLI はインストールおよび設定済みだと伝えている場合は、 インストールの確認、ログイン、認証情報の調査、プロファイルの変更、トランスポートの切り替えを 行わないでください。コマンドを実行する前に、指定されたリファレンスを読んでください。 以下のインストール、認証、プロファイル管理の手順は、手動で単独セットアップを行う場合にのみ 使用してください。

インストール（手動セットアップ）

npm install -g @duvoai/cli
duvo --version

Node.js ≥ 22.22.0 が必要です。グローバルインストールを行わずに npx @duvoai/cli <cmd> を使用することもできます。

認証（手動セットアップ）

duvo は認証情報をディスク上の 名前付きプロファイル として保持します。 （チーム、環境）の組み合わせごとに 1 つのプロファイルを使用します。最初に追加されたプロファイルがデフォルトになり、 以降のコマンドは、指定がない限りすべてデフォルトを使用します。

duvo login                       # OAuth flow — opens your browser
duvo login --name acme           # name the profile up front
duvo login --api-key <key>       # skip OAuth and store an API key directly
duvo whoami                      # confirm who's signed in

duvo login は、Duvo の本番テナントに対する ブラウザーベースの OAuth をデフォルトで使用します。 代わりに有効期間の長い API キーを保存するには、--api-key <key> を指定してください（https://app.duvo.ai/settings/api-keys から取得できます）。

プロファイルの切り替え：

duvo profiles list               # show all profiles; `▶` marks the default
duvo profiles use                # interactively pick the default profile
duvo profiles use acme           # set a named profile as the default
duvo --profile acme whoami       # one-off override for a single command

解決の優先順位（最初に一致したものが適用されます）：

• プロファイル：--profile <name> フラグ → DUVO_PROFILE 環境変数 → 設定ファイルの defaultProfile。
• 認証情報：DUVO_API_KEY 環境変数（プロファイルに保存された認証情報の参照を迂回します）→ プロファイルに保存された認証情報。
• ベース URL：DUVO_API_BASE_URL 環境変数 → プロファイルの apiBaseUrl → https://api.duvo.ai。
• チーム：--team <id> フラグ → DUVO_TEAM_ID 環境変数 → プロファイルの defaultTeamId → アクティブな認証情報から導出されたチーム。チームスコープの API キーでは異なる --team は拒否されますが、ユーザースコープのキーでは、ユーザーがアクセスできる任意のチームを選択できます。

ヘルプの参照

コマンドの構文については references/commands.md を読んでください。すべてのコマンドで --help も使用できます。管理セッションでは、ホストランタイムで許可されている場合にのみ使用してください。 単独利用の場合、以下のヘルプコマンドでインストール済みバイナリの情報を確認できます。

duvo --help                      # global help, lists every top-level group
duvo agents --help               # subcommand group
duvo agents create --help        # exact flags for one command

バイナリがドキュメントに記載されたフラグを受け付けない場合は、そのヘルプにインストール済み バージョンの情報が記載されています。フラグを推測したり、単独利用向けのヘルプ例を 管理セッションの調査手順として扱ったりしないでください。

出力モード

各コマンドは、返す内容に応じてデフォルトの出力形式を選択します。

• 単一リソース（duvo agents get <id>、duvo runs get <id>）→ 人が読みやすいキーと値のテキスト。
• コレクション（duvo agents list、duvo runs list）→ リソースごとに 列の構成が固定されたテーブル。
• 上記のいずれかに --json を指定 → stdout に生の JSON を出力します。これはスクリプト向けの 安定した契約 です。テーブル形式やテキスト形式はバージョン間で変更されることがありますが、 JSON は jq や yq に安全に渡せます。

duvo agents list --team <target-team-id> --json | jq '.agents[].id'

スクリプトで使用する場合は、コマンドリファレンスに記載されているコマンドに --json を指定し、 応答を解析してください。テーブル出力は解析しないでください。列幅や切り詰めのしきい値は 公開契約の一部ではありません。エンドポイントによってエンベロープのキーは異なります。agents list は .agents[] を、queues list は .queues[] を、runs list は .data[] を、agents create は .agent.id を返します。jq のパスを固定する前に、--json を指定して一度実行し、データの形状を 確認してください。

duvo apiという回避手段

公開 API のあらゆるエンドポイントに、gh apiを直接参考にしたduvo api <METHOD> <path>でアクセスできます。次のような場合に使用します。

• 新しい公開エンドポイントが追加されたものの、専用のduvo コマンドがまだ用意されていない場合。
• 上位レベルのコマンドでは指定できない、非常に限定的なクエリ文字列や本文の形式が必要な場合。
• デバッグする場合。duvo apiでは、API から返された内容が加工されず、そのまま表示されます。

duvo apiはパスをそのまま渡します。上位レベルのコマンドのように --team／DUVO_TEAM_ID／プロファイルの既定値を解決しないため、エンドポイント固有のパスを明示してください。ルートの形式はリソースごとに異なります。チームをスコープとするコレクション（/v2/teams/<team_id>/agents）もあれば、フラットなコレクション（/v2/artifacts）もあり、ID を指定するルートでもチームをスコープとするものがあります（/v2/teams/<team_id>/invites/<id>）。 推測せず、GET /v2/documentation/json（生の OpenAPI ドキュメント。/v2/documentationは Swagger UI の HTML）から正確なパスを確認してください。

duvo api GET "/v2/teams/$TEAM_ID/agents" -F limit=20 -F offset=0
duvo api POST "/v2/teams/$TEAM_ID/agents" -f name="Ops bot" -F [email protected]
duvo api POST "/v2/teams/$TEAM_ID/agents" --input body.json
cat body.json | duvo api POST "/v2/teams/$TEAM_ID/agents" --input -

-fは値を文字列として送信します。-Fは値を型付きで解析します（ブール値、数値、JSON のnull、またはディスクから JSON を読み込むための@file）。フラグ一覧はreferences/api-escape-hatch.mdを参照してください。

duvo agents createのような上位レベルのコマンドは、duvo apiの糖衣構文です。HTTP クライアント、出力パイプライン、終了コードを共有しているため、スクリプト内で両者を自由に組み合わせられます。

リソースグループ

フラグを含むコマンドツリー全体については、references/commands.md を参照してください。 最上位のグループは次のとおりです。

• 認証とプロファイル — login、logout、whoami、profiles …
• 自動化 — automations …（一覧表示、作成、取得、現在の設定、フロー、名前変更、複製、削除、エージェントとキューの追加／削除、タブ）およびそのポリシー：automations config-fields、add-config-field、edit-config-field、set-config-field、hide-config-field、restore-config-field、config-sections …
• エージェント — agents …、agents delete、agents move、agents duplicate／clone、agents models、agents set-model、agents case-triggers …、agents schedules …、agents triggers …、agents slack-triggers …、agents memory …、agents eval-scores、agents eval-rubrics …
• 提案 — suggestions …（接続の提案：一覧表示、適用、拒否）
• エージェントフォルダー — agent-folders …（エージェントをツリー形式で整理）
• リビジョン — revisions …、revision-integrations …（バージョン管理された設定）
• 実行 — runs …（開始、取得、メッセージ、停止、HITL への応答、評価）
• キューとケース — queues …、queues eval-rubrics …、queues aggregations …（型付きケースデータに対する Cube 形式の集計）、queue-labels …、cases …、cases search
• 通知 — notifications …（一覧表示、取得、フィード、バッチ取得、件数、未読件数、既読にする、バッチを既読にする、すべて既読にする、非表示、既読を削除、すべて削除）
• ファイルとサンドボックス — files …、sandboxes …
• 接続とインテグレーション — integrations …、connections …、oauth …
• シークレットと認証情報 — secrets …（環境変数のシークレット）、credentials …（ブラウザーのログイン情報）、revision-secrets …、revision-logins …
• Clarity — clarity …（プロセス検索、バージョン、キャプチャ、ギャップ、エビデンス、ファセット、エクスポート、生成、昇格、アーティファクトのインポート、招待リンク、doctor、プロセス全体図、プロセスリンク、プロセスタグ、プロセスの要約）
• Pulse — pulse …（作成、取得、一覧表示、メッセージ送信、ファイル添付、更新、停止、名前変更、共有、複製、別のチームへの移動、PDF／スナップショットのエクスポート、バージョン履歴、復元、メッセージ、HITL への回答、接続、コメントスレッド、Pulse ダッシュボードの削除、キューデータソースの接続／切断を行う pulse data …）
• スキルとプラグイン — skills …、plugins …
• チーム — team current、team get、team members、team set-role、team remove-member、team leave、team use、teams list、teams org、teams orgs、teams create-org-team、teams create-workspace、teams org-agents、teams org-insights、teams org-metrics、teams org-runs、teams org-usage
• 招待 — invite list、invite create、invite bulk、invite update、invite resend、invite delete、invite org-member、invite link get|create|delete
• 同梱ガイド — guide …（AI エージェント向けの、バージョンに対応した CLI ガイド）
• 自己更新 — update（インストール済みの CLI を最新バージョンに更新）
• 低レベル — api <method> <path>

一連の手順を最初から最後まで確認できるレシピ（エージェントの作成 → 実行の開始 → HITL への応答、キューとそのケースの管理、サンドボックスでの実行に使うファイルのアップロード、カスタム MCP サーバーの認証）については、references/workflows.md を参照してください。

オートメーション

オートメーションに移行したチームでは、すべてのエージェントとキューがオートメーションに属します。これは、Web アプリで1つのプロセスを表すコンテナーです。

• duvo automations create --name <name> は、オートメーションと最初のエージェントを作成します。--json のレスポンスには automation.id と first_agent_id が含まれます。別のエージェントを作成するのではなく、最初のエージェントを設定してください。
• duvo queues create では --automation-id <id> が必須です。指定しない場合、API は409を返します：「このチームはオートメーションに移行したため、新しいエージェントまたはキューはオートメーション内に作成する必要があります。」
• duvo agents create でも同じ --automation-id を指定できます。指定しない場合、バックエンドはエージェント名を付けた新しいオートメーションを作成します。1つのプロセスに属するすべてのエージェントを1つのオートメーションにまとめるには、このフラグを指定してください。
• duvo automations list で ID を確認できます。duvo automations current <id> では、そのオートメーションが現在実行するエージェント、キュー、トリガー、スケジュールを確認できます。

まだ移行していないチームでは、automations コマンドは403を返します（「このチームはオートメーションに移行していないため、利用できるオートメーションがありません。」）。エージェントとキューはフラグを指定せずに作成します。

推奨する構築順序

CLI からプロセスを構築する場合は、次の順序で進めてください。各ステップは1つ前のステップに依存します。

1. 接続。 エージェントが使用するすべてのサービスについて、duvo connections list --team <target-team-id> --type <slug> を確認します。不足している接続を先に行います（以下の「ネイティブ OAuth プロバイダーキー」を参照）。存在しない接続は後から固定できません。
2. オートメーション。 duvo automations create --name <name> --json を実行します。automation.id と first_agent_id を控えてください。
3. キュー、スキーマ、ラベル。 duvo queues create --name <name> --automation-id <id> を実行し、型付きケースには duvo queues schema create <queue-id> --file schema.json --name <name> を実行してから、duvo queue-labels create を実行します。スキーマルールと例は references/workflows.md のワークフロー4を参照してください。
4. エージェント。 残りのエージェントを --automation-id を指定して作成し、インテグレーションを追加し、OAuth またはユーザー提供の各スロットに接続を固定して、duvo queues link-agent でキューを接続します（コンシューマーの場合は --enable-trigger を指定します。ケーストリガーは初期状態ではオフです）。エージェントが参照する Policy の質問すべてに回答してください（以下の「Policy（設定フィールド）」を参照）。次に進む前に、references/workflows.md のワークフロー4にあるセットアップチェックリストを実行してください。
5. ケーストリガーをオンにする。 duvo agents case-triggers list <consumer-agent-id> --json の結果に enabled: true が表示される必要があります。pending_change が設定され、false と表示される場合、チームはオートメーションの変更を下書きとして保存しています。トリガーは、Duvo アプリのオートメーションのヘッダーにある Make active を誰かがクリックしたときにのみオンになり、CLI から実行するコマンドはありません。ユーザーに操作を依頼してください。それまでは、テストケースは Pending のままです。
6. テスト実行。 duvo runs start --agent <id> を実行するか、テストケースを1件キューに追加して、duvo runs get <run-id> で結果を確認します。
7. スケジュールは一時停止状態で作成。 ユーザーの IANA タイムゾーンを明示的に指定してください：

   duvo agents schedules create <agent-id> --frequency workday --time 07:30 \
     --timezone Europe/Prague --disabled
   duvo agents schedules update <agent-id> <schedule-id> --enable   # after the test run is right
   

   スケジュールを作成したユーザーには、そのエージェントの承認リクエストが届きます（以下の「承認リクエストは実行の作成者に届きます」を参照）。

Policy（設定フィールド）

オートメーションの Policy には、しきい値、メールボックス、送信者リストなどの型付きの回答が保存されます。担当者が調整する値は、AOP のテキストではなくここに設定してください。エージェントの AOP に <DUVO:CONFIG key="<key>" name="<label>"> が含まれている場合、エージェントはそのフィールドを読み取ります。各実行には現在の回答が渡されるため、回答を変更しても新しいリビジョンは必要ありません。読み取るフィールドに回答がない場合、実行は拒否されます。

エージェントは Policy に書き込めません。 値は Policy 画面、duvo automations set-config-field、またはユーザーの指示に基づく Ask Duvo を通じて変更します。エージェントが実行中に学習したルールは、ファイルまたはエージェントのメモリに保存してください。コマンド、回答の種類、値の形式、--fill-mode、--binding については、references/commands.md の「Policy（設定フィールド）」を参照してください。

Clarity のインタビューに招待する

複数のインタビュー参加者を招待する場合は、duvo clarity interview-invites send <process-id> を優先し、--invitee フラグを繰り返し指定してください。1 回のバッチで指定できる参加者は、重複を除いて最大 25 人です。 invite bulk はチーム専用です。--no-interview または --process-role を使う場合は、invite create を使用してください。 参加者の選定と配信処理については、インタビュー招待のワークフローを参照してください。1 人ずつ招待するループは避けてください。

すべてのコマンドで共通して適用される規則

これらはすべてのコマンドグループに適用されます。コマンドごとに繰り返すのではなく、CLI を説明する際にまとめて伝えてください。

• --profile <name> はグローバルフラグで、1 回の実行に限り、デフォルトのプロファイルを上書きします。
• --team <id> はグローバルフラグで、リクエストのチームスコープを使用するコマンドの解決済みチームを上書きします。管理対象のセッションでは、設定済みのデフォルトと同じ場合でも、該当するコマンドには必ず対象チームを明示的に指定してください。対象の選択には、ホストの指示に従ってください。リソース ID を使うコマンドでは、このフラグが無視される場合があります。生の API パスは書き換えられません。コマンド固有の所有者指定フラグ（landscape の propose-process --team を含む）は所有者を割り当てるため、デフォルトのチームを機械的に指定してはいけません。組織コマンドでは、ドキュメントに記載されたとおり、--org または位置引数の組織 ID を使用します。OAuth プロファイルとユーザースコープの API キープロファイルでは、アクセス可能なチームを選択できます。チームスコープの API キープロファイルでは、別のチームを指定すると拒否されます。
• API にアクセスするほぼすべてのコマンドで --json を使用でき、スクリプトではこの形式を使用してください。コマンドのヘルプまたはリファレンスに記載されている場合にのみ使用してください。サポートされていないフラグを作り出したり、テーブル出力を解析したりしてはいけません。
• 破壊的な操作（duvo logout、duvo profiles remove、duvo runs stop、duvo agents delete、duvo agents move、duvo agent-folders delete、duvo cases delete、duvo cases clear、duvo cases bulk-delete、duvo cases bulk-reprocess、duvo cases bulk-update-status、duvo cases bulk-update-priority、duvo skills delete、duvo skills revisions delete、duvo queues delete、duvo secrets delete、duvo automations delete、duvo automations remove-agent、duvo automations remove-queue、duvo credentials delete、duvo revision-secrets detach、duvo revision-logins detach、duvo revision-integrations remove、duvo revision-integrations connections unpin、duvo agents schedules delete、duvo agents case-triggers delete、duvo agents triggers delete、duvo agents slack-triggers delete、duvo agents eval-rubrics remove、duvo agents eval-rubrics replace、duvo queues eval-rubrics remove、duvo queues eval-rubrics replace、duvo connections delete、duvo queue-labels delete、duvo queues aggregations delete、duvo integrations custom delete、duvo clarity process-labels delete、duvo suggestions reject、duvo files delete、duvo pulse delete、duvo pulse move、duvo notifications delete-read、duvo notifications delete-all、duvo team remove-member、duvo team leave、…）は、TTY では確認を求め、標準入力が非 TTY の場合は拒否します。確認を省略するには -y / --yes を渡してください。プロンプトを回避するために CLI に yes をパイプしてはいけません。パイプ入力から推定した同意は明示的に拒否されます。
• 終了コード：0 は成功、1 は一般的なエラー、2 は認証エラー（キーがない、無効なキー、不明なプロファイル）、3 は見つからないことを示します。失敗の種類に応じて処理を分岐したい CI スクリプトで役立ちます。
• ID は引用符なしで出力されるため、シェルのパイプラインや $() にそのままコピーできます。

  agent=$(duvo agents create --team <target-team-id> --name "Ops bot" --input "What to do" --json | jq -r .agent.id)
  duvo runs start --agent "$agent"
  

• 非推奨の警告は stderr に出力されるため、--json の stdout を汚しません。また、警告を無効にすることはできません。予期しない警告が報告された場合は、@duvoai/cli のバージョンが古くないか確認してください。

落とし穴と注意点

• プロファイルと認証情報の違い。 --profile foo は読み込むプロファイルを変更します。DUVO_API_KEY=… は認証情報を上書きしますが、選択したプロファイルの apiBaseUrl は引き続き使用します。まったく異なる環境を対象にするには、DUVO_API_KEY と DUVO_API_BASE_URL の両方を設定してください。
• 引数なしの profiles use は、TTY でのみ動作する対話形式の選択画面を開きます。CI では、必ず名前を明示してください。
• agents create はデフォルトで対話形式です。 --name と --input を省略し、stdin が TTY の場合、CLI がプロンプトを表示します。CI では、入力待ちで処理が止まらないよう、両方のフラグを渡してください（初回ビルドを行わない場合は --no-build も指定してください）。
• cases create --from-file - は stdin から JSON を読み込みます。ファイル（または stdin）には、単一のケースオブジェクト、または最大 100 件のケースの配列を指定します。各ケースは { "title": "…", "data": "…", "labels": [{ "key": "…", "value": "…" }] } です。key のないラベルは、タグのみのラベルです。
• サンドボックスファイルとチームファイルの違い。 duvo files … は永続的なチームファイル（UI の Files 画面に表示されます）を管理します。duvo sandboxes … は単一の実行用にファイルをステージングします（duvo runs start --sandbox-id <id>）。混同しないでください。
• コネクションとインテグレーションの違い。 duvo integrations list はチームのインテグレーションタイプのカタログを表示します。duvo connections list はユーザーが実際に接続したアカウント（OAuth／認証情報のフローごとに 1 件）を表示します。OAuth ベースのコネクション（Gmail、Slack など）は duvo connections create ではなく、duvo oauth native start <provider> で開始します。後者はユーザーが提供する MCP サーバー専用です。
• connections list が空でも、ユーザーとチームごとの状態を示しています。 選択したチーム内で、呼び出し元ユーザーのコネクションと、そのチームと共有されているコネクションを一覧表示します。integrations list の行では、常に has_oauth_tokens: false と表示されます。これはアカウントではなく、カタログ上の項目だからです。そのため、コネクションが 0 件でインテグレーションが一覧表示されている場合、このユーザーはまだこのチームで何も認証していません。アカウントが存在しないと判断する前に、duvo whoami と指定した --team を確認してください。
• ネイティブ OAuth プロバイダーキーはインテグレーションタイプではありません。 oauth native start に渡すのはプロバイダーキーです。これは integrations list --json の oauth_provider_key で確認できます（Gmail は google_gmail、Google Calendar は google_calendar、Outlook は microsoft_outlook です）。タイプ（gmail）を渡すと、「Unknown OAuth provider」が返されます。キーが null の場合、そのインテグレーションはネイティブ OAuth ではありません。HubSpot、Asana、Attio、Amplitude、Supabase、Notion、Granola、Apify は MCP OAuth で接続します。それぞれのサーバー URL と --integration-type は、references/commands.md の「OAuth flows」に記載されています。 duvo oauth mcp authorize --url https://mcp.hubspot.com --name HubSpot --integration-type hubspot。 キーが null のその他の項目は、ウェブアプリで接続してください。
• アタッチ済み ≠ 接続済み。 revision-integrations attach は、リビジョン上にインテグレーションのスロットを作成するだけです。OAuth やユーザー提供のインテグレーション（HubSpot、Gong、Slack、カスタム MCP など）を実行で使用するには、ユーザーのコネクションのいずれかをそのスロットにピン留めする必要があります。コネクションがピン留めされていないアタッチ済みスロットは、実行時に「not connected」で失敗しますが、アタッチ時には警告されません。duvo connections list --team <target-team-id> --type <slug> でコネクションを見つけ、duvo revision-integrations connections pin でピン留めし、duvo revision-integrations connections list で確認してください（各スロットに 1 件以上あることを確認します）。デフォルトのインテグレーション（browser、Exa、human-in-the-loop、case-queue-producer／case-queue-consumer など）にはピン留めは不要ですが、case-queue スロットには代わりにキューのマッピングが必要です。duvo revision-integrations case-queue-setup で確認してください。references/workflows.md のワークフロー 7 とワークフロー 4 のセットアップチェックリストを参照してください。
• コンシューマーのないキューでは、ケースは Pending のままです。 ケースを取得するものがないため、誰かが手動で閉じる（duvo cases bulk-update-status）まで Pending のままになります。プロデューサーだけが書き込む「audit」や「log」キューは作成しないでください。実行内容を記録するには、エージェントにファイルを書き込ませる（duvo files …）か、コンシューマーがあるキューに実行ごとにダイジェストケースを 1 件追加してください。
• 承認リクエストは実行の作成者に届きます。 human-in-the-loop リクエストは、その実行の所有者に届きます。スケジュール実行の所有者はスケジュールを作成したユーザーで、ケース起動型の実行の所有者はそのケースに対する前回の実行の所有者です。前回の実行がない場合は、ケースの作成者に届きます。API キーで作成したスケジュールは、そのキーのユーザーが所有者になります。リクエストはそのユーザーの Requests 受信トレイに届くため、承認に回答するユーザーとしてスケジュールを作成してください。
• シークレット、コネクション、認証情報の違い。 これらは別々の 3 つのストアです。duvo secrets は実行時に実行へ注入される環境変数のキー／値ペアを保持します。duvo credentials はブラウジングエージェントが使用するブラウザーのログイン情報（ドメインとパスワード、任意の TOTP）を保持します。duvo connections は外部サービス（Gmail、Slack、カスタム MCP など）への OAuth／API キーコネクションを保持します。これらは互いに重複しません。シークレットは revision-secrets、ログイン情報は revision-logins、コネクションのスロットは revision-integrations connections pin でアタッチしてください。
• 複数チームでの OAuth とユーザースコープの API キープロファイル。 OAuth ログイン、またはサーバーによって単一のチームにピン留めされていない API キー（_ユーザースコープ_のキー）は、複数のチームで使用できます。duvo teams list でチームをすべて確認し、リクエスト単位のコマンドには --team <id> を渡してください。手動セットアップでは、duvo team use <id> でプロファイルのデフォルトを設定することもできます。どちらの方法も、これらのプロファイルで使用できます。例外は_チームスコープ_の API キーです。サーバーがすでに 1 つのチームにピン留めしているため、--team で別のチームを指定することはできません。
• 期限切れの OAuth コネクションの再接続。 古いコネクションに対して新しいコネクションを作成しないでください。duvo connections list で既存のコネクションの ID を確認し、duvo oauth native start または duvo oauth mcp authorize に --reconnect-instance-id <id> を渡すと、重複を作成せずに既存のコネクションを再認証できます。
• Clarity には読み取りコマンドと明示的な書き込みコマンドがあります。 まず duvo clarity overview <process-id> を実行し、続いて versions、current、proposal、compare、gaps、evidence、readiness、facets を使ってプロセスを把握してください。書き込みコマンドは、ユーザーが Clarity の状態を変更したい場合にのみ使用してください。対象となる操作は、生成、昇格、復元、後処理、自動化のビルド、追加キャプチャエージェント、招待リンク、Miro アーティファクトのインポートです。v2 専用のこれらのコマンドには Clarity v2 のプロセスが必要です。レガシーの v1 プロセスでサポートされるのは、overview、status、captures、capture、export のみです。デフォルトの出力は簡潔です。トランスクリプトとメディア URL は、JSON コマンドで --include-transcripts を明示的に渡した場合にのみ含まれます。
• 通知：バッチと個別通知。 duvo notifications feed は、個別の通知と、エージェントまたはキューごとにグループ化された通知バッチを混在させて返します。get-batch と mark-batch-read が受け付けるのはバッチ ID（feed または通知の batchId から取得）だけで、個別の通知 ID は受け付けません。notifications list で --sort importance を指定するには --batch が必要です。--batch を省略すると、CLI がローカルで組み合わせを拒否します。
• Clarity のアーティファクトのインポートでは、内部で 2 段階の API を使用します。 ローカルの Miro SVG、XML、PNG、JPEG エクスポートには duvo clarity import-artifact <process-id> <file> を使用してください。署名付き URL の作成、バイトデータのアップロード、インポートの完了を行います。カスタムのアップロードクライアントやアーティファクトチャットのワークフローでは、公開ルートに対して duvo api を使用してください。
• Slack チャネルトリガーを使うには、先にワークスペースを接続する必要があります。 Slack ワークスペースがエージェントに紐付けられていないと、agents slack-triggers create は失敗します。作成前に agents slack-triggers workspaces <agent-id> で確認してください。チームにインストール済みのワークスペースが複数ある場合は、--workspace を渡してください。
• チームメンバーの管理では、コマンドごとに必要なロールの下限が異なります。 team set-role には Manager 以上が必要です（Owner ロールの付与または削除ができるのは Owner のみです）。team remove-member には Superadmin 以上が必要です。team leave はすべてのメンバーが使用できます。いずれのコマンドも、最後に残った Owner に対する操作は拒否します。
• Pulse にファイルを添付する方法は 2 通りあります。 duvo pulse send-message <id> --message <text> --attach-file <path> は、ファイルをアップロードし、メッセージ内で参照する処理を 1 回で行います。指示内容がすでに決まっている場合に使用してください。duvo pulse attach <id> <file> はファイルをステージングして添付 ID を出力するだけです。指示を別途作成または送信する場合（例：スクリプトでメッセージ本文を作成する場合）に使用してください。どちらもファイルは最大 5 件、1 件あたり最大 25MB という同じ制限があります。

CLI が適切なツールではない場合

次のケースでは、ユーザーに別の画面を案内してください。

• 実行中のイベントをリアルタイムで読みたい場合。 CLI の runs get と runs messages は、特定の時点での読み取りです。runs start に --webhook-url を指定してイベントを非同期で受信するか、Web UI で実行を開いてください。
• AOP またはエージェントの設定を対話的に編集したい場合。 revisions create と revisions update では設定ファイルを指定できますが、設定を手作業で作成するのは手間がかかります。AOP だけを変更する場合は、代わりに --aop-file で Markdown ファイルを指定してください。小規模で対象を絞った修正以外は、Web UI の Agent エディターを案内してください。
• Duvo 上ではなく、自分のプロセス内でエージェントを実行したい場合。 これは公開 API が提供する機能ではありません。CLI はホスト型の Duvo プラットフォームを利用するクライアントです。

スキル内のリファレンス

• references/commands.md — リソース別に分類された、フラグを含むすべてのコマンドツリー。コマンドに必要な正確なフラグを確認するときに参照してください。
• references/workflows.md — エンドツーエンドの手順（エージェントの作成と実行の開始、HITL を介した意思決定、キューとケースのライフサイクル、ケースのスキーマと重複排除、アップロードしたファイルを使ったサンドボックス実行、カスタム MCP サーバーの認可）。
• references/api-escape-hatch.md — duvo api のフラグリファレンス。-f と -F の使い分け、@file の型付きフィールド、未加工の JSON ボディに対する --input の実例を記載しています。

操作を行う前に、該当するコマンドリファレンスを確認してください。マネージドセッションでヘルプに切り替える場合は、ホストのランタイム指示に従ってください。

関連項目

• aop-writer — Build に含める AOP を作成または書き換えます（duvo revisions create / duvo revisions update）。
• run-debugger — 失敗した Run を診断します。API モードで読み取る場合は、duvo runs get、duvo runs messages、duvo revisions get と組み合わせます。
• workflow-debugger — 多数の Run を対象に、Agent またはワークフローを監査します。duvo runs list、duvo queues agents、duvo revisions get と組み合わせます。

リソース

• Duvo — 製品ウェブサイト
• Duvo ドキュメント — 概念、Agent の構築、Connections
• Duvo API リファレンス — CLI がラップするすべてのエンドポイント
• @duvoai/cli on npm — バージョン、インストール手順、変更履歴
• Web アプリ — CLI でスクリプト化できるすべての操作を行う対話型画面
• API キー — duvo login --api-key 用の API キーを発行および無効化します
• 公開スキルリポジトリ — MIT ライセンスのコミュニティ版スキル。サードパーティ製の Claude Code 環境にインストールできる形式でパッケージ化されています