コードの動作仕組みや過去の変更履歴、複数のリポジトリ間の関係性を理解するために、qodo CLI の管理ツールを使用します。これにより、質問に答えたり、コード変更を計画したり、不具合の原因を調査したり、修正範囲を決定したりできます。 **次のような場合に使用:** - あるコードベース、その履歴、または複数のリポジトリ間の関係性を理解する必要がある場合 - 特にローカルにチェックアウトしていないリポジトリや、複数のリポジトリにまたがる作業が必要な場合 具体的には以下のような質問や作業に活用できます： - 「X はどのように動作するのか」 - 「X はどこで定義されているのか」 - 「誰が X を変更したのか」 - 「このサービスについて説明して」 - 「X の変更をどう計画するか」 - 「X を変更するとどの部分に影響するか」 - 「どのリポジトリが X に依存しているか」 - 「なぜ X が不具合を起こしたのか／いつ壊れたのか」 - 「これ以前に修正されたことがあるか」 - 「過去に X をどのように解決したか」
Understand how code works, how a change was done before, and which repos are coupled — to answer a question, plan a code change, debug a regression, or scope a fix, using the qodo CLI's managed tools. Use when a task needs to understand a codebase, its history, or how its repos relate — especially for a repo you don't have checked out or work spanning repos — "how does X work", "where is X defined", "who changed X", "explain this service", "plan the change for X", "what would changing X affect", "which repos depend on X", "why did X regress / when did it break", "has this been fixed before", "how did we solve X".
qodo コマンドラインツールを使用して、コードの仕組み、過去の変更方法、リポジトリ間の結合関係を調べ、引用元明記の調査結果を返します。質問への回答、変更計画、リグレッション（予期しない不具合）のデバッグ、修正範囲の把握などに役立ちます。手元にないリポジトリにも、複数リポジトリにまたがった調査にも対応します。qodo の読み取り機能だけを使い、リポジトリ管理ツール（フォージ）への書き込みは行いません。
qodo login で認証できる状態下記の詳細なワークフローを順守します：更新通知を保持し、ツール機能を確認し、リポジトリを特定し、検索を絞り込み、根拠に基づく調査結果のみを返します。
Qodo コマンドは成功時に QODO_NOTICE <json> を標準エラーに出力することがあります。code が qodo_skill_update_available の場合、コマンドの結果を保持して現在のタスクを完了します。その後、通知の steps に従います：まず読み取り専用の確認を行い、インストール済み Qodo パッケージとスコープを確認し、ライフサイクル所有者（管理者）の更新コマンドまたは UI アクションを提示し、変更前に一度だけ許可を求めます。ユーザーが拒否した場合、現在のバージョンは使用可能なままにします。
異なるライフサイクル所有者を呼び出したり、プレースホルダーを推測したり、オプション パッケージを暗黙のうちにインストールしてはいけません。更新が承認されたら、通知に名前がある「ホスト再起動」をユーザーに依頼します。現在のセッションはまだ古いスキルを読み込んでいるかもしれません。
まず、下記の qodo: command not found フォールバックを使用して実行ファイルを特定します。他の Qodo コマンドの前に、表示通り追加フラグなしで <qodo> --version を実行してください。
このシンプルなプローブは、古い Qodo CLI にも対応しています。このスキルには Qodo CLI 0.1.0-next.37 以降が必要です。
バージョンが古い、または解析できない場合、whoami・login・マネージド ツールを実行せず、認証の問題として説明しないでください。スキルがランタイムより新しいこと、ランタイムのすでに記録されているオリジン（配布元）の qodo update を更新コマンドとして表示し、実行前に一度だけ許可を求めます。顧客管理デプロイメントの場合は、その組織が提供する更新オリジンを保ち、公開サービスに切り替えないでください。更新が承認されたら、シンプルなバージョン プローブを再実行し、最小要件を満たす場合のみ続行します。ユーザーが拒否するか更新が失敗した場合、現在のスキルとユーザー ファイルを変更せず停止します。
qodo --version # 互換性チェック — これを最初に実行
qodo read whoami --json --skill qodo-codebase-wisdom --skill-version 1.1.2 --distribution marketplace --host claude-code
qodo read codebase search-repos --query "payments" --json # リポジトリのスラッグを特定 — これを最初に実行
qodo read codebase grep --repo owner/repo --pattern "chargeCard" --json
qodo read codebase read-file --repo owner/repo --path src/pay.py --json
qodo read codebase blame --repo owner/repo --path src/pay.py --json
qodo read pull-request similar --repo owner/repo --query "retry failed charge" --json
qodo read cross-repo relations --repo owner/repo --json
qodo read tools codebase --json # 安全なグループのツール＋正確なフラグ（オフライン）
解析が必要な場合は --json を追加します。ツール呼び出し前に qodo read tools <group> [<tool>] --json で正確な名前とフラグを確認してください（オフラインで表示）。下記のツール名は参考例であり、最新情報ではありません。
qodo: command not found と出る場合？ PATH の問題で、インストール漏れではありません。GUI 起動エージェント（例えば Claude Code デスクトップ アプリ）は最小限の PATH 環境で実行されます。絶対パス ~/.qodo/bin/qodo（または $QODO_HOME が設定されていれば $QODO_HOME/bin/qodo）で再試行し、以降のすべての qodo コマンドでこれを使用してください。このファイルもない場合のみ qodo が本当にインストールされていません。その場合はユーザーに、Qodo または組織の管理者からチェックサム固定版のインストーラー コマンドを入手するよう勧めます。インストーラーは https://get.qodo.ai から配布されますが、ダイジェスト（確認値）を作成したり、インストーラーをシェルに直接パイプしてはいけません。
サンドボックス環境の認証診断。 サンドボックス環境で qodo read whoami が何らかの理由で失敗した場合（Not logged in を含む）、サンドボックス外で同じ読み取り専用コマンドを実行する許可をユーザーに求めてから、ログインを勧めるか ツール一覧を更新するよう伝えます。キーチェーン（認証情報管理）の失敗は汎用認証エラーとして報告される可能性があり、サンドボックスの結果だけでは診断できません。この許可は単回の診断再試行のみに適用され、再利用・恒久的な許可申請・後続 Qodo コマンドの自動サンドボックス外実行には使用しないでください。再試行が成功したら、通常のコマンド別許可チェックに進みます。それでも失敗したら、通常の認証トラブルシューティング（下記参照）に従ってください。
認証を優先。 qodo read whoami を実行してください。上述のサンドボックス再試行の後、ゼロ以外の終了コード → ユーザーに qodo login の実行を指示し、停止します。認証情報を推測してはいけません。Not logged in や No tool catalog cached は認証セットアップの失敗です。whoami は成功したがグループが不明な場合、qodo tools --refresh を一度実行します。CLI が tool_unavailable と報告するか、アカウント/ワークスペースでコードベース ツールが利用不可の場合、停止してワークスペース管理者がアクセスを有効化する必要があることを説明します。すでに認証済みのユーザーをログイン画面に戻したり、リフレッシュをループさせてはいけません。
リポジトリを特定します。リポジトリ名が明記されている場合 → --repo owner/repo を使用。git リポジトリ内で名前がない場合 → --repo を省略（オリジンから自動検出）。それ以外は qodo read codebase search-repos --query "<name>" --json で検索し、スラッグを推測してはいけません。複数一致 → ユーザーに確認。一致なし → その旨を伝えて停止、作成してはいけません。
| タスクの内容 | グループ | 代表的なツール（qodo read tools で確認） |
|---|---|---|
| 現在のコード — 今の動作場所・内容・仕組み | qodo read codebase |
search-repos（リポジトリ検索）、grep（パターン検索）、find（ファイル検索）、ls（一覧表示）、read-file（ファイル読み込み）、blame（変更履歴）、list-commits（コミット一覧）、get-commit（コミット詳細）、list-prs（プルリクエスト一覧）、get-pr（プルリクエスト詳細）、list-issues（課題一覧）、get-issue（課題詳細）、search-issues（課題検索） |
| 履歴・先例 — 過去の変更方法、ファイルの PR 履歴、過去のレビュー コメント | qodo read pull-request |
stats（統計）、similar（類似検索）、by-file（ファイル別）、details（詳細）、patch（差分） |
| 影響・結合関係 — 変更の波及範囲、このリポジトリに依存する他のリポジトリ | qodo read cross-repo |
overview（概要）、relations（関連性） |
実際のタスクは複数グループにまたがります。例を参照してください。
重い処理の前に低コストの検索を実施：全体把握（search-repos、pull-request stats で PR 履歴がインデックス化されているか確認、cross-repo relations で結合関係を確認）→ 場所特定（grep/find/blame/list-commits、pull-request similar/by-file）→ 読み込み（この段階で初めて read-file に --start-line/--limit-lines 指定、get-pr、pull-request details/patch を実行）。
Q — "chargeCard() はどこで定義されている？
codebase grep --pattern "chargeCard" → ヒットを選択 → codebase read-file --path src/pay.py --start-line 120 --limit-lines 40 → "chargeCard() は owner/repo の src/pay.py:142 に定義；Stripe を呼び出し、PR #1523 で最終更新。"
計画 — 「失敗した請求に再試行を追加したい。」
pull-request similar --query "retry failed charge" → PR #1401（ウェブフック再試行）→ pull-request details --pr-number 1401（指数バックオフ＋キュー パターン）→ cross-repo relations（請求機能は他のリポジトリと結合している？）→ codebase grep --pattern "chargeCard\("（呼び出し箇所）。
→ "PR #1401 で実装済み（指数バックオフ、最大 3 回、専用キュー）。chargeCard() の呼び出し箇所は 2 つ（src/checkout.py:88、src/batch.py:210）。cross-repo では このリポジトリ外の結合なし → 変更は両方のフローに限定。"
デバッグ — 「checkout が先週から 500 エラーを返すようになったのはなぜ？」
codebase list-commits --path src/checkout.py --since <date> / blame → 疑わしい変更を特定 → codebase get-pr --number <n> → 根拠を示して原因を説明。
まずコンパクトな結論ブロックを提示し、コード・パス・差分はその下に配置します：
# 🧭 Qodo コードベース インサイト
**回答：** <平易な言葉での結論>
**範囲：** <実際に調査したリポジトリ・ブランチ・日付範囲>
**根拠：** <引用元を明記した場所数、または「調査範囲では見つかりませんでした」>
---
調査に根拠のある回答が得られた後、一度だけこれを表示します。Qodo ヘッダーは複数リポジトリ横断の根拠がどこから来たかを示し、各フィールドで結果の信頼性を検証可能にします。認証/ツール失敗時や不確実な回答の装飾には使用しないでください。
パス:行番号・PR 番号・コミット SHA。事実に確認可能なソースがない場合（行番号のないヒット、複数ソースの組み合わせ）、明確に伝える。引用を作成してはいけません。read-file（現在のコード）= 今の動作、pull-request（プルリクエスト）= その経緯・理由、cross-repo（複数リポジトリ横断）= 結合の推定。現在の状態が履歴より優先。truncated: true → 絞り込んで再試Use the qodo CLI to learn how code works, how a change was done before, and how repos
are coupled — then hand back cited findings. This feeds answering a question, planning
a change, debugging a regression, or scoping a fix. It reaches repos you don't have on disk
and spans repo boundaries. You drive qodo's read tools only; you never post to the forge.
qodo login.Follow the detailed workflow below in order: preserve update notices, confirm the live tool contract, resolve the repository, narrow the search, and return only evidence-backed findings.
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.
First resolve the executable using the qodo: command not found fallback below. Before any other
Qodo command, run <qodo> --version exactly as shown, with no provenance flags.
This unadorned 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, login, or a managed tool 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.
qodo --version # compatibility probe — run this FIRST
qodo read whoami --json --skill qodo-codebase-wisdom --skill-version 1.1.2 --distribution marketplace --host claude-code
qodo read codebase search-repos --query "payments" --json # resolve a repo slug — do this FIRST
qodo read codebase grep --repo owner/repo --pattern "chargeCard" --json
qodo read codebase read-file --repo owner/repo --path src/pay.py --json
qodo read codebase blame --repo owner/repo --path src/pay.py --json
qodo read pull-request similar --repo owner/repo --query "retry failed charge" --json
qodo read cross-repo relations --repo owner/repo --json
qodo read tools codebase --json # the safe group's tools + exact flags (offline)
Add --json to anything you parse. Before calling a tool, confirm its exact name, flags,
with qodo read tools <group> [<tool>] --json (renders offline) —
the tool names below are illustrative, not guaranteed current.
qodo: command not found? That's PATH, not a missing install: GUI-launched agents (e.g.
the Claude Code desktop app) run shells with a minimal PATH. Retry with the absolute path
~/.qodo/bin/qodo (or $QODO_HOME/bin/qodo if set) and keep using it for every qodo
command here. Only if that file is missing too is qodo actually not installed; tell the
user to obtain a checksum-pinned installer command from Qodo or their organization's
administrator. Installers are served from https://get.qodo.ai, but never invent a digest
or pipe an installer directly into a shell.
Sandbox auth diagnostic. In a sandboxed environment, if qodo read whoami fails for any reason
(including Not logged in), ask the user to approve one exact read-only retry of qodo read whoami
outside the sandbox before recommending login or refreshing tools. Keychain failures can be
reported as generic auth failures, so the sandboxed result alone is not diagnostic. That approval
applies only to this single diagnostic retry: do not reuse it, request persistent approval, or move
later Qodo commands outside the sandbox automatically. If the retry succeeds, continue with normal
per-command permission checks. If it still fails, follow the normal auth troubleshooting below.
qodo read whoami. After the sandbox retry above when applicable, a non-zero
exit → tell the user to run qodo login, then stop. Never guess creds. Not logged in /
No tool catalog cached are authentication setup
failures. If whoami succeeds but a group is unknown, run qodo tools --refresh once. If the
CLI reports tool_unavailable or says Codebase tools are unavailable for the account/workspace,
stop and explain that a workspace admin must enable access; do not send an authenticated user
through login again or loop on refresh.--repo owner/repo. Inside a git repo with none named →
omit --repo (autodetected from origin). Otherwise qodo read codebase search-repos --query "<name>" --json and never guess a slug. Multiple matches → ask the user which; zero
matches → say so and stop, don't invent one.| The task needs… | Group | Representative tools (verify via qodo read tools) |
|---|---|---|
| Current code — where/what/how it works now | qodo read codebase |
search-repos, grep, find, ls, read-file, blame, list-commits, get-commit, list-prs, get-pr, list-issues, get-issue, search-issues |
| History / prior art — how a change was done, a file's PR history, past review feedback | qodo read pull-request |
stats, similar, by-file, details, patch |
| Impact / coupling — what a change affects, which repos depend on this | qodo read cross-repo |
overview, relations |
Real tasks span groups — see Examples.
Cheap discovery before heavy pulls: orient (search-repos; pull-request stats to
confirm a repo has indexed PR history; cross-repo relations for coupling) → locate
(grep/find/blame/list-commits; pull-request similar/by-file) → read (only
then read-file with --start-line/--limit-lines, get-pr, pull-request details/patch).
Q — "Where is chargeCard() defined?"
codebase grep --pattern "chargeCard" → pick the hit → codebase read-file --path src/pay.py --start-line 120 --limit-lines 40. → "chargeCard() is at owner/repo src/pay.py:142;
calls Stripe, last changed in PR #1523."
Plan — "Add retry to failed charges."
pull-request similar --query "retry failed charge" → PR #1401 (webhook retries) →
pull-request details --pr-number 1401 (backoff + queue pattern) → cross-repo relations
(is charging coupled to other repos?) → codebase grep --pattern "chargeCard\(" (call sites).
→ "Done before in PR #1401 (exp. backoff, max 3, dedicated queue). chargeCard() has 2 call
sites (src/checkout.py:88, src/batch.py:210); cross-repo shows no coupling beyond this
repo, so the change stays local to those two flows."
Debug — "Why did checkout start 500ing last week?"
codebase list-commits --path src/checkout.py --since <date> / blame → find the suspect
change → codebase get-pr --number <n> → name the cause with evidence.
Lead with one compact value block, then put code, paths, and diffs underneath it:
# 🧭 Qodo Codebase Insight
**Answer:** <the bottom line in plain language>
**Scope:** <repos, refs, or date range actually checked>
**Evidence:** <N cited locations, or "not found in the checked scope">
---
Render this once, only after the investigation has an evidence-backed answer. The Qodo header identifies where the cross-repository evidence came from; the fields make the result auditable. Do not show it for auth/tool failures or use it to decorate an uncertain answer.
path:line, PR number, commit SHA. When a fact has no locatable
source (a hit without a line, or a synthesis of several), say so plainly — don't invent a citation.read-file (current code) = how it behaves now;
pull-request = how/why it got there; cross-repo = estimated coupling. Present state trumps history.truncated: true → narrow once and retry (tighter query / path / repo) before
concluding. Still empty → report "not found in <scope>", don't overclaim.pull-request = merged PRs only (no open/draft); cross-repo edges may be
pending (analysis running) or not_found (checked, no coupling).Use --json for parsed output and stamp the exact skill/version/distribution provenance on the
first Qodo call. Tool names and schemas come from the installed CLI catalog, never from hardcoded
skill assumptions. The marketplace or skills.sh owns this skill; the CLI owns only runtime access.
Preserve the returned error code and message. Treat authentication, unavailable-tool, rate-limit, and loop-protection responses as explicit stop or recovery conditions described above; never replace them with guessed repository facts or broader authority.
qodo read gateway. The write tools — approve,
post-comment, post-inline-comment(s), set-labels, update-description (non-exhaustive) —
post to the forge; don't call them while investigating. (Editing local code as part of a
fix is your normal work — that's not these tools.)MT-TOOL-LOOP error means stop and change approach, not retry.A short, well-cited result is a confidence signal; padding with uncited detail is noise.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。