Qodo（開発効率化ツール）をローカルの開発支援エージェント（コードを書く際にサポートするAI機能）に接続します。Qodo CLIの確認、不足時の安全なインストール案内、ブラウザでのログイン完了、管理ツールの準備完了を確認します。 **次のような場合に使用:** - Qodoプラグインをインストール後 - ユーザーがQodoのセットアップまたは接続を求めた時 - 他のQodoスキルがCLIの不足またはログアウト状態を報告した時
Connect Qodo to the current local coding agent — verify the Qodo CLI, guide a secure installation when it is missing, complete browser login, and confirm managed tools are ready. Use after installing the Qodo plugin, when the user asks to set up or connect Qodo, or when another Qodo skill reports that the CLI is missing or logged out.
Qodo のマーケットプレイス インストールを一連の初期セットアップフローに変える。ローカルランタイム（コンピュータ内で実行される環境）を探し出し、ブラウザログインでユーザー認証を行い、このエージェントが管理ツールを使用できることを確認する。ユーザーに対して、認証情報をチャットに貼り付けるよう求めることは決してない。
以下の 4 段階ワークフローに従う。ライフサイクル（利用開始から終了までの段階）の通知は保持したまま、ランタイムを解決し、ユーザー認証を行い、ID と ツール準備を確認した後、ブランド化されたハンドオフを正確に 1 回表示する。
Qodo コマンドは QODO_NOTICE <json> を標準エラーに出力しながら成功することがある。code が qodo_skill_update_available の場合、コマンドの結果を保持し現在のタスクを終了する。その後、通知の steps に従う。読み取り専用の在庫確認をまず行い、インストール済み Qodo パッケージと範囲を解決し、ライフサイクル所有者による正確な更新コマンドまたは UI アクション（画面での操作）を表示し、変更前に 1 回だけ承認を求める。ユーザーが拒否した場合は、現在のバージョンを使用可能な状態に保つ。
異なるライフサイクル所有者を起動したり、プレースホルダーを推測したり、オプションパッケージを暗黙的にインストールしたりしない。承認された更新後、通知で名前が指定されたホスト再起動をユーザーに求める。現在のセッションではまだ古いスキルが読み込まれている可能性がある。
以下を実行:
qodo --version
POSIX シェル（標準的なコマンド実行環境）で qodo: command not found と表示される場合は、標準ユーザースコープ（ユーザー単位の）の場所で再試行:
"${QODO_HOME:-$HOME/.qodo}/bin/qodo" --version
Windows PowerShell では、ネイティブランチャーを使用:
$qodoHome = if ($env:QODO_HOME) { $env:QODO_HOME } else { Join-Path $HOME '.qodo' }
& (Join-Path $qodoHome 'bin/qodo.cmd') --version
後続のすべてのステップで動作するコマンドを保持する。PATH を自動的に書き換えない。
どちらのコマンドも存在しない場合、ユーザーに以下を伝える:
Qodo スキルはインストールされていますが、ローカルランタイムがありません。チェックサム検証済みの Qodo コマンドラインツールを https://get.qodo.ai から、または組織の Qodo 管理者から取得し、その後に「Qodo セットアップ」を実行してください。
ここで停止する。チェックサムを作成したり、リモートスクリプトをシェルにパイプしたり、非公式レジストリ（登録簿）からパッケージを使用したり、ユーザーの承認なしにソフトウェアをインストールしたりしない。
実行可能ファイルが見つかった場合は、続行する前にその出力を評価する。装飾なしのバージョン確認は、意図的に古い Qodo コマンドラインツールとの互換性がある。このスキルには Qodo コマンドラインツール 0.1.0-next.37 以降が必要。
バージョンが古い場合、またはパースできない場合、whoami または login を実行せず、エラーを認証の問題と説明しない。スキルがランタイムより新しいこと、ランタイムの既に記録されている出所の更新コマンドとして <qodo> update を表示し、実行する前に 1 回だけ承認を求める。顧客デプロイメント（組織によるシステム展開）の場合は、その組織が提供する更新出所を保持し、決してパブリックサービスに切り替えない。承認された更新後、装飾なしのバージョン確認を再実行し、最小要件を満たす場合のみ続行する。ユーザーが拒否するか、更新が失敗した場合は、現在のスキルとユーザーファイルを変更せずに停止する。
<qodo> read whoami --json --skill qodo-setup --skill-version 1.0.5 --distribution marketplace --host claude-code を実行。
サンドボックス環境では、whoami の失敗は ログアウトではなく、キーチェーン（パスワード保管機能）がブロックされている場合がある。その正確な読み取り専用コマンドを 1 回だけサンドボックス外で再試行する承認を求める。承認は当該診断再試行のみに適用される。成功した場合は通常どおり続行。承認された再試行も失敗した場合のみ、ユーザーをログアウト状態として扱う。
Not logged in、認証情報なし、または非ゼロ認証結果の場合: 以下のログインパスを選択。デプロイメントエンドポイントが解決されるまでログインを実行しない。unknown command または unknown option は、認証の失敗ではなくランタイム契約違反。正確なエラーを報告して停止。ユーザーをログインを通す必要なし。ブラウザを開く前に、ログインコマンドを選択:
<qodo> login を実行。<qodo> login --auth-url <their-url> など、デプロイメント固有の正確なコマンドを保持。qodo logout がauth エンドポイントを保持していたと報告）がある場合は、プレーンな <qodo> login も安全。コマンドラインツールは保持されたエンドポイントをクラウドデフォルトより先に解決。単に保持されていると想定しない。qodo login はブラウザを開く可能性がある。実行前にユーザーに何が起きるか説明。コマンド完了まで待機。ブラウザを開いただけでログイン成功を主張しない。ユーザーがキャンセルするか、ログインが失敗した場合: エラーメッセージを保持し、Qodo がまだ接続されていないことを説明し、他の Qodo スキルを呼び出さずに停止。
ログイン後、両方を実行:
<qodo> read whoami --json --skill qodo-setup --skill-version 1.0.5 --distribution marketplace --host claude-code
<qodo> tools --refresh --json --skill qodo-setup --skill-version 1.0.5 --distribution marketplace --host claude-code
構造化された結果を読む。準備状態には、成功した認証済みIDと使用可能なツールカタログの両方が必要。プロセス起動の成功だけでは不足。
whoami が成功しているときカタログ更新が失敗した場合: 認証は完了したが管理ツールの準備ができていないこと、返されたエラー、および安全な再試行コマンド qodo tools --refresh を報告。whoami が失敗しない限り、ユーザーをログインに通さない。
最初に動作する Qodo 実行可能ファイルのパスとすべての明示的な --auth-url をセットアップ全体で保持。最初の Qodo 呼び出しで正確なスキル/バージョン/ディストリビューション由来を記録。マーケットプレイスまたは skills.sh がこのスキルパッケージを所有。コマンドラインツールがログイン、ランタイム、ツールカタログ更新を所有。
ホストが Kiro で安全な読み取りが繰り返し促される場合: 次の読み取り前にオプションの永続ルールを説明。提供する唯一の広いパターンは <qodo> read *。当該コマンドラインゲートウェイは、ライブカタログで明示的に非変更とマークされていないすべての管理ツールを拒否。バージョン確認を独自の正確な <qodo> --version ルールとして保持。<qodo> * または <qodo> codebase * を提案したり、エージェントから Kiro パーミッションファイルを編集したりしない。ユーザーは Kiro の 常に許可 アクションと範囲を選択するか、Qodo Power で提供される生成済み qodo-read-only.permissions.yaml をレビューできる。
ランタイム不在、キャンセルされたログイン、ID 失敗、またはツール不可用で停止し、正確で安全な次のアクションを報告。ブラウザを開く、プロセスを起動、または部分的なカタログ更新を成功した準備状態の主張に変えない。
両方の確認が合格した場合、更新されたカタログからのカウントを使用して以下を正確に 1 回表示:
# ✅ Qodo Ready
Account: **connected**
Managed tools: **<N> available**
Runtime: **<version from qodo --version>**
---
ID とカタログの両方の確認が成功した後にのみ準備完了ブロックを表示。スタートアップバナーではなく、検証されたハンドオフ。ログイン保留中、部分的なセットアップ後、またはツールカウントが不明な場合は表示しない。その後、最も短い関連次のアクションを提案:
qodo-reviewqodo-get-rules が利用可能な場合のみ使用。そうでない場合は、オプションの Qodo Standards アドオンに属することを説明。現在のエージェント マーケットプレイスを通じてアドオンをインストール、または qodo agents install --standards --json を使用して、ローカル互換エージェントを検出し、インストールなしで別々の正確な skills.sh コマンドを出力。qodo-codebase-wisdomqodo-review-resolverユーザーが要求するまで、これらのワークフロータスクのいずれも実行しない。セットアップは機能を確立。レビュー、編集、投稿、または標準管理の許可を推測しない。
Turn a marketplace install into one guided first-use flow: find the local runtime, authenticate the human through Qodo's browser login, and verify that this agent can use the managed tools. Never ask the user to paste credentials into chat.
Follow the four-stage workflow below: preserve lifecycle notices, resolve the runtime, authenticate the user, verify identity and tool readiness, then show the branded handoff exactly once.
A Qodo command can emit QODO_NOTICE <json> to stderr while still succeeding. When
code is qodo_skill_update_available, keep the command's result and finish the current
task. Then follow the notice's steps: do read-only inventory first, resolve the installed
Qodo package and scope, show the exact lifecycle-owner update command or UI action, and ask
once before any mutation. If the user declines, keep the current version usable.
Never invoke a different lifecycle owner, guess a placeholder, or install an optional package implicitly. After an approved update, ask for the host restart named by the notice; the current session may still have the old skill loaded.
Run:
qodo --version
If a POSIX shell reports qodo: command not found, retry the standard user-scoped location:
"${QODO_HOME:-$HOME/.qodo}/bin/qodo" --version
In Windows PowerShell, use the native launcher:
$qodoHome = if ($env:QODO_HOME) { $env:QODO_HOME } else { Join-Path $HOME '.qodo' }
& (Join-Path $qodoHome 'bin/qodo.cmd') --version
Keep the working command for every later step. Do not rewrite PATH automatically.
If neither command exists, tell the user:
The Qodo skill is installed, but its local runtime is not. Obtain the checksum-verified Qodo CLI from https://get.qodo.ai or your organization's Qodo administrator, then ask me to “Set up Qodo” again.
Stop there. Do not invent a checksum, pipe a remote script into a shell, use a package from an unofficial registry, or install software without the user's approval.
If an executable was found, evaluate its output before continuing. The unadorned version probe is
intentionally compatible with older Qodo CLIs. This skill requires Qodo CLI 0.1.0-next.37 or newer.
If the version is older or cannot be parsed, do not run whoami or login and do not
describe the failure as an authentication problem. Explain that the skill is newer than the runtime,
show <qodo> update as the update command for the runtime's already-recorded origin, and ask once
before running it. For a customer deployment, keep its organization-provided update origin; never
switch it to the public service. After an approved update, rerun the unadorned version probe and
continue only when it satisfies the minimum. If the user declines or the update fails, stop with the
current skill and user files unchanged.
Run <qodo> read whoami --json --skill qodo-setup --skill-version 1.0.5 --distribution marketplace --host claude-code.
In a sandboxed environment, any failed whoami can be a blocked keychain rather than a logged-out
user. Ask for approval to retry that exact read-only command once outside the sandbox. The approval
applies only to that diagnostic retry. If it succeeds, continue normally; only treat the user as
logged out when the approved retry also fails.
Not logged in, missing credentials, or a
non-zero authentication result: choose the login path below. Do not run login until its
deployment endpoint is resolved.unknown command or unknown option after the successful version gate is a runtime-contract
failure, not an authentication failure. Report the exact error and stop; do not send the user
through login.Choose the login command before opening a browser:
<qodo> login.<qodo> login --auth-url <their-url>.<qodo> login is also safe for a customer deployment only when this interaction has
explicit evidence that CLI 0.1.0-next.37 or newer already retained that endpoint—for example,
an earlier qodo logout reported that it kept the auth endpoint. The CLI resolves a retained
endpoint before the cloud default; never merely assume one was retained.qodo login may open a browser. Tell the user what is happening before you run it. Wait for
the command to finish; never claim login succeeded from a browser opening alone. If the
user cancels or login fails, preserve the error message, explain that Qodo is still not
connected, and stop without invoking other Qodo skills.
After login, run both:
<qodo> read whoami --json --skill qodo-setup --skill-version 1.0.5 --distribution marketplace --host claude-code
<qodo> tools --refresh --json --skill qodo-setup --skill-version 1.0.5 --distribution marketplace --host claude-code
Read the structured results. Readiness requires both a successful authenticated identity and a usable tool catalog. A successful process launch by itself is not enough.
If catalog refresh fails while whoami succeeds, report that authentication is complete
but managed tools are not ready, including the returned error and the safe retry
qodo tools --refresh. Do not send the user through login again unless whoami fails.
Keep the first working Qodo executable path and any explicit --auth-url for the entire setup.
Stamp exact skill/version/distribution provenance on the first Qodo call. Marketplace or skills.sh
owns this skill package; the CLI owns login, runtime, and tool-catalog refresh.
When the host is Kiro and safe reads prompt repeatedly, explain the optional persistent rule before
the next read. The only broad pattern to offer is <qodo> read *: that CLI gateway rejects every
managed tool not explicitly marked non-mutating by the live catalog. Keep the version probe as its
own exact <qodo> --version rule. Never suggest <qodo> * or <qodo> codebase *, and never edit
Kiro permission files from the agent. The user may choose Kiro's Always allow action and scope,
or review the generated qodo-read-only.permissions.yaml supplied with the Qodo Power.
Stop on missing runtime, canceled login, failed identity, or unavailable tools and report the exact safe next action. Never convert a browser opening, process launch, or partial catalog refresh into a successful readiness claim.
When both checks pass, show this once using counts from the refreshed catalog:
# ✅ Qodo Ready
Account: **connected**
Managed tools: **<N> available**
Runtime: **<version from qodo --version>**
---
Only show the ready block after both identity and catalog checks succeed. It is a verified handoff, not a startup banner: do not show it while login is pending, after a partial setup, or when the tool count is unknown. Then offer the shortest relevant next action:
qodo-reviewqodo-get-rules only when it is available. Otherwise,
explain that it belongs to the optional Qodo Standards add-on; install that add-on through
the current agent marketplace, or use qodo agents install --standards --json to detect local
compatible agents and print their separate exact skills.sh commands without installing anything.qodo-codebase-wisdomqodo-review-resolverDo not run one of those workflows until the user asks. Setup establishes capability; it does not infer permission to review, edit, post, or administer standards.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。