Qodoを現在のローカル（手元のパソコン上で動作する）コーディングエージェント（プログラミングを支援するツール）に接続します。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 段階ワークフローに従う：ライフサイクル（ソフトウェアの更新・廃止に関わる通知）を保持し、実行環境を解決してからユーザー認証し、本人確認とツール準備状態を検証し、ブランド化されたハンドオフ（引き渡し）を正確に 1 回だけ表示する。
Qodo コマンドは成功時、標準エラー出力に QODO_NOTICE <json> を出力することがあります。code が qodo_skill_update_available の場合、そのコマンドの結果は保持して現在のタスクを完了する。その後、通知内の steps（手順）に従う：まず読み取り専用の状況確認、インストール済み Qodo パッケージとスコープを解決し、ライフサイクル所有者（管理者）が指定した更新コマンドまたは UI 操作を正確に表示し、変更を加える前に一度だけ確認する。ユーザーが断った場合、現在のバージョンを使用可能な状態で保つ。
異なるライフサイクル所有者を呼び出したり、プレースホルダーを推測したり、オプションパッケージを無断でインストールしてはいけない。更新が承認されたら、通知で指定されたホスト（ノード）の再起動をユーザーに求める：現在のセッションには古いスキルがまだ読み込まれている可能性がある。
以下を実行する：
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 スキルはインストール済みですが、ローカル実行環境がありません。https://get.qodo.ai またはあなたの組織の Qodo 管理者から、チェックサム検証済みの Qodo CLI を入手したうえで、私に「Qodo をセットアップして」と言ってください。
ここで止める。チェックサムを作成したり、リモートスクリプトをシェルにパイプしたり、非公式レジストリからパッケージを使ったり、ユーザーの承認なくソフトウェアをインストールしてはいけない。
実行可能ファイルが見つかった場合、その出力を評価してから続ける。簡潔なバージョン確認は、意図的に古い Qodo CLI とも互換性がある。このスキルには Qodo CLI 0.1.0-next.37 以降 が必要。バージョンが古いか解析できない場合は、whoami や login を実行せず、これを認証の失敗と説明してはいけない。スキルが実行環境より新しいことを説明し、<qodo> update をその実行環境の既に記録されたソース（取得元）からの更新コマンドとして表示し、実行する前に一度だけ確認する。顧客デプロイメント（企業向け配置）の場合、その組織が提供した更新ソースを保持し、公開サービスに切り替えてはいけない。更新が承認されたら、簡潔なバージョン確認を再実行し、最小要件を満たすようになったときのみ続ける。ユーザーが断ったか更新が失敗した場合、現在のスキルとユーザーファイルを変わらないままで止める。
<qodo> read whoami --json --skill qodo-setup --skill-version 1.0.5 --distribution marketplace --host claude-code を実行する。
サンドボックス環境では、whoami の失敗は、ログアウト状態ではなくキーチェーン（認証情報の保管場所）がブロックされているだけかもしれない。その正確な読み取り専用コマンドをサンドボックス外で一度だけ再試行することを承認するよう求める。その承認はその診断再試行のみに適用される。成功した場合、通常通り続ける：ユーザーがログアウト状態と見なすのは、承認された再試行も失敗したときだけ。
Not logged in（ログインしていない）、認証情報なし、またはゼロ以外の認証結果：以下のログイン方法を選ぶ。ログインをデプロイメント エンドポイント（接続先）が解決されるまで実行してはいけないunknown command（不明なコマンド）または unknown option（不明なオプション）は、認証の失敗ではなく、実行時契約（CLI との通信規約）の失敗。正確なエラーを報告して止める：ユーザーをログインフローに送ってはいけないブラウザを開く前にログインコマンドを選ぶ：
<qodo> login を実行する<qodo> login --auth-url <その URL> ）を保持する<qodo> login は顧客デプロイメントでも安全。ただし、CLI 0.1.0-next.37 以降がそのエンドポイント情報をすでに保持していることが、この対話で明白な証拠がある場合のみ（例：以前の qodo logout がその認証エンドポイント情報を保持したと報告した）。CLI は保持されたエンドポイント情報をクラウドデフォルトより前に解決する：単に保持されていると想定してはいけない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
構造化された結果を読む。準備状態には、成功した認証済み身元と使用可能なツールカタログの両方が必要。プロセスが立ち上がっただけでは不十分。
whoami は成功したがカタログ更新が失敗した場合、認証は完了しているが管理ツールが準備できていないと報告し、返されたエラーと安全な再試行コマンド qodo tools --refresh を含める。whoami が失敗しない限り、ユーザーをログインフローに送り直してはいけない。
最初に動作する Qodo 実行可能ファイルのパスと明示的な --auth-url をセットアップ全体を通じて保持する。最初の Qodo 呼び出しで、スキル・バージョン・配布形態の正確な由来を記す。マーケットプレイス または skills.sh がこのスキルパッケージを所有；CLI がログイン・実行環境・ツールカタログ更新を所有する。
ホストが Kiro で安全な読み込みが繰り返し求められる場合、次の読み込みの前にオプションの永続ルールを説明する。提案する広いパターンは <qodo> read * のみ：その CLI ゲートウェイは、ライブカタログで明示的に非変更（読み取り専用）とマークされたすべての管理ツール以外を拒否する。バージョン確認をその独自の正確な <qodo> --version ルールとして保持する。<qodo> * や <qodo> codebase * を提案してはいけず、エージェントから Kiro パーミッションファイルを編集してはいけない。ユーザーは Kiro の Always allow（常に許可）アクション・スコープを選ぶか、Qodo Power で提供される生成済み qodo-read-only.permissions.yaml を確認するかできる。
実行環境の欠落、ログインキャンセル、身元確認失敗、またはツール利用不可で止め、正確な安全な次のアクションを報告する。ブラウザの開閉、プロセス立ち上げ、部分的なカタログ更新を、準備完了の成功に変えてはいけない。
両方のチェックが通ったら、更新されたカタログの数値を使用して以下を正確に 1 回表示する：
# ✅ Qodo Ready
Account: **connected**
Managed tools: **<N> available**
Runtime: **<version from qodo --version>**
---
身元とカタログ両方のチェックが成功した後のみ、準備完了ブロックを表示する。これは検証済みハンドオフであり、起動バナーではない：ログイン待機中、部分的セットアップ後、またはツール数が不明な場合に表示してはいけない。次に、最も短い関連する次のアクションを提案する：
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 による自動翻訳です。