qodo-get-rules

ルールの取得

説明

Qodo の管理ツールを使って、現在のタスクに最も関連するワークスペースのコーディングルールを取得し、コードの作成時に適用してください。取得結果はセマンティック検索で決まります。返される内容の質はクエリの書き方によって左右されるため、以下のクエリ形式に正確に従ってください。

前提条件

• オプションの Qodo Standards パッケージがインストールされ、明示的に読み込まれていること。
• 接続済みの QAR 管理ツール MCP サーバー、または認証済みの Qodo CLI からルール検索を利用できること。
• セマンティッククエリを作成できる程度にタスクが具体的であること。すでに読み込まれたルールは再利用されます。

手順

実行経路の選択

まず適用可能な既存の検索結果を再利用してください。新たに取得する場合は、ホストに接続された QAR MCP の rules-search ツールがあり、読み取り専用としてマークされていれば使用してください。それ以外の場合は、以下の CLI 経路に従います。MCP では、ホストが提供する inputSchema と JSON 引数（query、top_k、任意の scopes 配列）を使い、構造化クエリごとに 1 回呼び出します。scopes が不明な場合は省略してください。CLI の省略フラグの代わりに空の配列を送信してはいけません。isError を確認してから structuredContent を読み取ってください。型付きの失敗情報は保持し、読み取りに失敗した結果をルールが空であるかのように扱ってはいけません。MCP 機能が利用できない、または禁止されている場合でも、CLI のログイン失敗として扱ってはいけません。別のアカウントやテナントへ黙って切り替えないでください。

以下の詳細なワークフローに従ってください。更新通知を保持し、現在のツール仕様を確認し、焦点を絞ったセマンティッククエリを作成し、順位付きの結果を統合して、適用される制約を説明してから適用します。まず Preflight の再利用条件を確認してください。以前の検索結果でタスクを引き続き網羅できる場合は、Output に進んでから適用します。この経路ではランタイム、ID、カタログ、検索の確認は不要です。

スキルの更新通知への対応

QODO_NOTICE の更新は、古い CLI が操作を要求する場合でも、受動的な通知として扱ってください。インベントリや更新について質問せずにタスクを続行し、各イベントへの言及は 1 回までにしてください。通知を閉じても、記録済みの保守ポリシーやオプトアウト設定は変更されません。更新されたスキルは次のセッションで読み込まれます。現在のセッションを中断しないでください。ユーザーが更新を依頼した場合は、手動更新の手順に従ってください。

実行

• MCP：実際のスキーマ引数を使用し、CLI のシェル手順は省略します。
• CLI：BOM なしの完全な UTF-8 ファイルを使用します（ツールには --args-file、レビューには --context-file）。例は POSIX 用です。
• Windows CLI：最初の呼び出しの前にシェルのガイダンスを読んでください。ランチャーの復旧手順は、呼び出しに失敗した場合に限り参照してください。解決した呼び出し方法を再利用してください。

ランタイム互換性ゲート

取得経路を使用する場合に限り、以下の qodo: command not found のフォールバックに従って実行ファイルを解決してください。他の Qodo コマンドを実行する前に、<qodo> --version を記載どおり正確に実行します。出所確認のフラグは付けません。このフラグなしの確認方法は、古い Qodo CLI との互換性を意図したものです。このスキルには Qodo CLI 2.0.0 以降が必要です。 Windows の場合、PowerShell または Git Bash で最初に Windows シェルを読んでください。

バージョンが古い場合、またはバージョンを解析できない場合は、whoami、login、管理ツールを実行せず、失敗を認証の問題として説明しないでください。このスキルがランタイムより新しいことを説明してください。自動更新はメジャーバージョンの範囲内で行われます。Qodo または組織が提供するチェックサム固定のインストーラーを使って 2.x を明示的にインストールする前に、ユーザーに一度だけ確認してください。顧客向けデプロイでは、組織が提供する更新元を維持し、公開サービスへ切り替えてはいけません。承認を得て更新した後は、フラグなしのバージョン確認を再実行し、最低要件を満たした場合にのみ続行してください。ユーザーが拒否した場合、または更新に失敗した場合は、現在のスキルとユーザーファイルを変更せずに停止してください。

クイックスタート

qodo --version                                             # compatibility probe — run this FIRST
qodo read whoami --json --skill qodo-get-rules --skill-version 1.1.7 --distribution skills-sh
qodo read rules search --query "Name: JWT Authentication Endpoint Validation
Category: Security
Content: Implementing a login endpoint that validates credentials and issues JWT tokens securely" --top-k 20 --scopes "/owner/repo/" --json
qodo read tools rules --json                              # exact safe flags (renders offline)

引用符で囲まれた --query の値の中の改行はリテラルです。複数行の二重引用符付き文字列は、POSIX sh/bash/zsh でそのまま使用できます。Bash 専用の $'…' 引用は使わないでください。PowerShell では、クエリ全体を保持するために、Windows shells に記載された検証済みのネイティブ呼び出しを使用してください。引用符の扱いと UTF-8 JSON ファイルに関するガイダンスに従ってください。

qodo: command not found と表示されますか？ POSIX では "${QODO_HOME:-$HOME/.qodo}/bin/qodo" を再試行してください。Windows ではリンク先のガイドに従ってください。解決した呼び出し方法はそのまま使用し、起動できないランチャーは報告してください。インストールされていない場合は、Qodo または管理者が提供する、チェックサムが固定されたインストーラーを入手してください。ダイジェストを推測したり、スクリプトをシェルにパイプしたりしないでください。

サンドボックス認証の診断。 認証情報がない場合、キーチェーンにアクセスできないことが原因の可能性があります。その可能性があるときは、ログインを推奨する前に、ホストの承認フローを通じて、読み取り専用の qodo read whoami を正確に一度だけ再試行するよう依頼してください。拒否されたら中止してください。この承認は他のコマンドには適用されません。成功した確認結果は、同じ実行ファイル、ワークスペース、デプロイ、実行コンテキスト内で再利用してください。必要なホストの承認は都度求めてください。ネットワーク、TLS、サービス、明示的な認可に関するエラーはそれぞれ個別に診断し、ログインの推奨やサンドボックスの自動回避は行わないでください。

事前確認

1. 関連する証拠を再利用します。 見出しや、ルールを読み込んだという以前の主張ではなく、実際に取得したルールとその適用範囲を再利用してください。ワークスペース、リポジトリ、またはタスクの対象が変わった場合は、新しい対象範囲のルールを取得してください。以前の空の結果を再利用できるのは、確認した対象範囲に限られます。取得に失敗した場合は、空の結果とはみなしません。以前の結果でタスクを引き続きカバーできる場合は、再取得を省略して直接適用してください。ここで事前確認を終了し、Qodo のコマンドを実行せずに出力へ進みます。更新の明示的な依頼がある場合は、それに従ってください。
2. 認証とカタログ — 再取得が必要な場合に限ります。 この実行コンテキストを引き続きカバーする成功済みの確認結果がない限り、qodo read whoami を実行してください。該当する場合はサンドボックス診断を行った後、ログインが必要なのは認証情報が明示的に不足している場合に限ります。組織指定のログインコマンド／エンドポイントをそのまま使用し、推測したり、顧客のデプロイ先を Cloud に切り替えたりしないでください。No tool catalog cached は認証情報が不足している証拠ではありません。qodo tools --refresh で一度更新してから、確認を再試行してください。それ以外のエラーはそのまま保持し、このワークフローを中止してください。本人確認に成功した後、管理対象のコマンドが不明な場合は、カタログの更新とスキーマの再確認を一度だけ行えます。それでも見つからない場合、または tool_unavailable の場合は、利用できない機能を報告してください。ログインや更新を繰り返さないでください。
3. リポジトリの対象範囲（任意。精度が向上します）。リポジトリの origin リモートから、ホストより後ろの完全なパスを取得し、末尾の .git を取り除きます。git@host:a/b と https://host/a/b はどちらも a/b として解析され、より深いホスト型パスはそのまま保持されます（GitLab のサブグループ group/subgroup/repo、Azure DevOps の org/project/repo など。2 セグメントにまとめないでください）。/<path>/ の形式にします。cwd がリポジトリのルート内の modules/<name>/ サブディレクトリにある場合は、/<path>/modules/<name>/ に絞り込みます。リモートがない、または解析できない場合は、--scopes を完全に省略してください（組織全体の検索は引き続き利用できます）。空の scopes 値は絶対に渡さないでください。

クエリを作成する

構造化クエリを2つ作成します。検索データによると、トピックを1つだけ指定したクエリでは、実際のレビューで大きな比重を占める、複数の変更にまたがる標準ルールを体系的に見落とします。 各クエリは、ルールのインデックス方法に合わせた3行のブロックです。

Name: <concise 5-10 word title of the rule this task would trigger>
Category: <one of: Security, Correctness, Quality, Reliability, Performance, Testability, Compliance, Accessibility, Observability, Architecture>
Content: <1-2 sentences describing what should be checked or enforced; mention the tech stack when known>

• トピッククエリ — 変更の主な目的を指定します。変更の目的に基づいてカテゴリを選び、副次的な影響で判断しないでください（レート制限 → セキュリティではなく信頼性）。セキュリティが本当に該当する場合は優先してください。すべてをデフォルトで正確性に分類しないでください。構造に関する作業はアーキテクチャ、スタイルは品質、耐障害性は信頼性、計測は可観測性です。
• 複数の変更にまたがるクエリ — 組織がすべての変更に適用する標準を指定します。デフォルト： Name: Code Quality and Standards Compliance / Category: Architecture / Content: Module directory structure, type annotations or type safety, structured logging, repository or service layer patterns, dependency injection, and naming conventions — Content はリポジトリの技術スタックに合わせて調整してください。
• キーワードの羅列、平坦な文章、埋め草（「お願いします」、「必要です」など）は決して渡さないでください。構造化インデックスに対する検索精度が低くなります。

検索と統合

クエリごとに1回ずつ検索します（可能であれば並行して実行します）。CLI では qodo read rules search を使い、--top-k 20 と --json を指定します。検出したスコープがある場合に限り、--scopes "$SCOPE" を追加します。MCP では rules-search を呼び出し、top_k: 20 と同じクエリを指定します。scopes 配列は任意です。以下のコマンド例は CLI の場合のみを示しています。

# With a detected scope:
qodo read rules search --query "$TOPIC_QUERY" --top-k 20 --scopes "$SCOPE" --json
qodo read rules search --query "$CROSS_QUERY" --top-k 20 --scopes "$SCOPE" --json

# Without a detected scope, omit both the flag and its value:
qodo read rules search --query "$TOPIC_QUERY" --top-k 20 --json
qodo read rules search --query "$CROSS_QUERY" --top-k 20 --json

Windows の Git Bash では、独立した /owner/repo/ 引数が Windows パスに書き換えられ、スコープを指定した検索でルールが何も返されないことがあります。Windows シェルの説明に従ってスコープを渡してください。

統合：まずトピックの結果を順番どおりに並べ、次にまだ含まれていない複数の変更にまたがる結果を追加します。ルールの id で重複を除外してください。トピックルールはタスク固有の指針です。複数の変更にまたがるルールは補足として扱い、タスクとの意味的な関連が薄いものは優先度を下げてください。 **検索結果が少ない場合のフォールバック：**トピッククエリで返されるルールが3件未満の場合は、Content の行を広げて関連する概念を追加し（例：認証 → トークンの検証、認証情報の取り扱い、セッション管理）、そのクエリを1回だけ再実行してから統合します。統合後のリストが空でも問題ありません。ルールの制約なしで続行し、エラーとして扱わないでください。 スコープを指定しない検索に関する注意：--scopes を省略する必要があった場合、検索結果は組織全体を対象とします。各ルールを適用する前に、対象のリポジトリや技術スタックに妥当な形で適用できるか確認してください（別のサービス、言語、フレームワークを名指しするルールは該当しません）。該当しないものはスキップし、他のリポジトリの標準を押し付けるのではなく、その旨を伝えてください。

出力してから適用

Qodo を通じて取得した関連標準 → この変更への影響 → 適用、または正当な逸脱の順で記述してください。コーディングを始める前に、組織の標準を取得した方法として、Qodo に一度だけ自然に言及してください。標準は組織に属するものです。適用される各ルールについて、現在のタスクに即して説明し、要約する場合も、ルール名、参照先、提示された重大度、および該当するすべての要件を維持してください。参照先が返されている場合はリンクまたは引用してください。存在しない識別子や重大度を作り出してはいけません。次のパターンを応用してください。「Qodo を通じて、チームの[トピック]標準を読み込みました。この変更では、[ルール]により、[実装上の選択とその理由]とします。」複数のルールがある場合は、短いリストにしてください。ブランド名を含む見出し、絵文字のバナー、スローガン、フッター、繰り返しの要約ブロックは使わないでください。適用される標準がない場合は、その旨を簡潔に述べてください。ツールのエラーが発生した場合に、取得に成功したかのように示してはいけません。標準の読み込みと適用を区別してください。読み込んだだけでは、準拠したことにはなりません。

作成するコードには、適用されるルールを反映してください。コーディング後、実装に影響したルールと、その適用を示す根拠を報告してください。リスト全体を繰り返す必要はありません。ユーザーの決定と実装上の根拠を示し、許可された逸脱（スキップした WARNING ルールを含む）を説明してください。ERROR のルールと矛盾する場合は、上記のゲートに従って解決してください。適用されるルールがなければ、その旨を明確に伝えてください。

設定

--json、タスクに厳密に関連するスコープ、CLI が現在提供しているルールのスキーマを使用してください。最初の認証済み Qodo 呼び出しでは、装飾なしのバージョン確認の直後に、スキル／バージョン／配布元のプロベナンス情報を記録してください。既定のパッケージを使って、このオプションのスキルを暗黙的にインストールまたは更新してはいけません。

エラー処理

空の結果は有効です。認証、機能、検証、レート制限に関するエラーはそのまま保持し、制限付きの復旧手順に従ってください。取得を安全に続けられない場合は、ルールを作り出さずに処理を続行してください。

ガードレール

• rules search は読み取り専用で、ワークスペースの状態を変更しません。
• 取得済みルールのスコープがタスクをカバーしている間は、そのルールを再利用してください。空の結果も有効です。
• レート制限エラー（組織ごとに検索回数の上限があります）が発生した場合は、指定されたリセット時刻まで待つか、ルールなしで進めてその旨を伝えてください。再試行を繰り返してはいけません。
• ルールを捏造してはいけません。返された内容をそのまま適用し、ルールは返された名前で引用してください。