メインコンテンツへスキップ
レビューディレクティブを使うと、その 1 回のレビューで Kody がどこを最も深く分析すべきかを指示できます。設定を変更する代わりに、レビューを起動するときに短い指示を添えます — 例えば「認証とセッションのロジックに集中して」— すると Kody は該当する変更コードに最も厳しい分析を集中させます。
ディレクティブは一時的です。その 1 回のレビュー実行にのみ適用され、設定には保存されず、今後のレビューには影響しません。Kody の挙動を恒久的に変えたい場合は、カテゴリの指示と Kody のパーソナリティ（指示とパーソナリティ、旧 Custom Prompts）または Kody Rules を使ってください。

​
いつ使うか

  • PR が多数のファイルに触れているが、特にリスクの高い 1 領域（認証、決済、マイグレーション）が気になるとき。
  • 特定の変更の呼び出し元・呼び出し先を Kody に辿らせ、より厳しく精査させたいとき。
  • レビューを再実行する際、設定を編集せずに注意を向けたいとき。

​
フィルターではなく優先度

これが最も重要なポイントです：
ディレクティブはフィルターではなく優先度を設定します。Kody はフォーカス領域を優先しますが、diff の他の箇所で気づいた具体的なバグ・セキュリティ・パフォーマンスの問題も引き続き報告します。フォーカス外の指摘を握りつぶすことはなく、PR の残りを未確認のまま承認することもありません。
ディレクティブは 「ここを最も重点的に見て」 と伝えるものであり、「ここだけ見て」 ではありません。

​
起動方法

プルリクエストのコメントで、レビューコマンドの直後にフォーカステキストを書きます：
start-review も使え、--force と組み合わせられます：
--force は、Kody が通常スキップする場合（「前回のレビュー以降に新しいコミットがない」）でもレビューを再実行します。フォーカスディレクティブの有無にかかわらず、前回の実行を失敗させた原因を修正した後に新しいレビューを実行したり、レビュー済みの PR に更新後の設定を適用したりする際に使ってください。
ディレクティブとして使われるのはコマンドの後の最初の 1 行のみです。以降の行は無視されるため、フォーカスは 1 行にまとめてください。
GitHub、GitLab、Azure DevOps、Bitbucket、Forgejo で動作します。

​
Heavy mode

フォーカスディレクティブは Kody にどこを重点的に見るかを伝えます。--heavy はより広く見る ことを伝えます。通常のレビューと並行して、9 つの専門レビュアーがそれぞれ diff 全体を読み、 1 種類の欠陥だけを探します：
  • 言っていることとやっていることが違うコード（名前、計測、結果）
  • 人に届くテキスト（メッセージ、コメント、翻訳）とコードの食い違い
  • 不正な状態、壊れた不変条件、競合状態
  • 境界・インデックス・順序についての前提
  • シークレットと認証情報：比較、正規化、フォールバック値
  • 変更された契約に呼び出し側が追従していない
  • カバーしている振る舞いが壊れても通ってしまうテスト
  • レスポンス、ログ、エラーメッセージへのデータ漏えい
  • 互いに食い違う 2 つの変更ファイル
専門レビュアーの指摘はすべて、投稿される前にメインレビューの指摘と同じ検証を通り、その後いつも どおりの重複排除と重要度付けを経ます。根拠のない推測は他の指摘と同様に取り除かれます。

​
デフォルトで Heavy に、または 1 回のレビューだけ

Code review → General の Review mode 設定で、リポジトリのすべてのレビューの実行方法を選びます：Balanced（デフォルト。メインレビューのみ） または Heavy。自動レビュー、@kody review、kodus review のすべてに適用されます。コマンドに フラグを付けると、そのレビューに限り設定を上書きします：
--heavy は Balanced に設定されたリポジトリで heavy レビューを実行し、--balanced は Heavy に 設定されたリポジトリで balanced レビューを実行します。両方を付けた場合は --heavy が優先されます。 どちらのフラグも行のどこに置いても構いません（フォーカステキストの前でも後でも）。いずれの場合も ディレクティブからは取り除かれるため、@kody review リトライ処理に注目 --heavy は 「リトライ処理に注目」にフォーカスします。 フラグは任意の順序で組み合わせられます。@kody review --heavy --force は強制の heavy レビューに なります。Kody がすでにレビューしたプルリクエストで、前回のレビューと異なるモードを指定すると、 それ以降のコミットだけでなくプルリクエスト全体をレビューします。 ダッシュは必須です。ダッシュなしの heavy や balanced はディレクティブのテキストとして読まれるため、 @kody review heavy チェックアウト経路 はフラグを有効にせず「heavy チェックアウト経路」に フォーカスします。

​
期待できること

  • すべての組織で利用可能です。クラウドでもセルフホストでも、申請は不要です。CLI ではログイン済みのチーム（kodus auth login）が必要です。トライアルのレビューは heavy なしで実行され、その旨が表示されます。
  • カテゴリ設定はそのまま適用されます。 オフにしたカテゴリの専門レビュアーは実行されません （7 つが Bug、2 つが Security）。Kody Rules とカスタムエージェントは通常どおり実行されます。
  • Heavy のモデルで実行されます。 AI providers → Routing → Code Review で、Model for Heavy が heavy レビューのモデルを、Model for Balanced が balanced レビューのモデルを選びます。 Heavy のモデルが未設定の場合、heavy レビューは組織のデフォルトを使います。Code review → General でリポジトリまたはディレクトリに設定したモデルは、両方のモードで使われます。
  • コストも時間も増えます。 30 件のプルリクエストでの評価では、同じモデルの Balanced と比べて、 heavy レビューはプルリクエストあたり最大で約 2 倍の時間と、約 2.5 倍のモデルコストがかかりました。 実際の問題はプルリクエスト 2 件につき約 1 件多く見つかり、実際の問題ではないコメントはプルリクエスト あたり約 1 件多く投稿されました。自分のモデルキー（BYOK）の場合、追加のコストはプロバイダーの請求に 含まれ、同時実行数の上限が低いプロバイダーでは呼び出しが待たされることがあります。
  • リポジトリにアクセスできない場合（サンドボックスなし）、専門レビュアーはメインレビューと 同様に diff だけを読みます。
  • プルリクエスト一覧では、最後のレビューが heavy mode で実行された PR に Heavy バッジが 表示されます。
見落としのコストが高いリポジトリ（決済サービス、認証モジュールなど）では Review mode を Heavy に 設定するか、リスクの高い単発の変更で --heavy を指定してください。

​
良いディレクティブの書き方

  • 判定ではなく領域を具体的に。「バグを見つけて」より「キューコンシューマの並行処理に集中して」の方が有効です。
  • 結果ではなくコードを名指しする。 モジュール・フロー・関心事を指し示します（「リトライロジック」「レポートサービスの SQL」）。
  • 短く。 ディレクティブは最大 500 文字で、コメントの最初の 1 行のみが読まれます。
  • @kody review 認証とトークンリフレッシュのフローに集中して
  • @kody review 新しい Stripe webhook 処理に集中して
  • kodus review --focus "バックグラウンドワーカーの競合状態"
  • @kody review しっかり見て — 優先すべき領域がありません。
  • @kody review ファイル X だけコメントして — ディレクティブはフィルターではありません。ファイルを絞るには Ignored files を使ってください。

​
注意点と制限

  • 長さ： ディレクティブは 500 文字で切り詰められます。
  • 最初の 1 行のみ： PR コメントでは、コマンド後の最初の 1 行だけがディレクティブになります。
  • 設計上、信頼しない： PR にコメントできる人なら誰でもディレクティブを渡せるため、使用前にテキストはサニタイズされます（制御文字と山括弧を除去）。これはフォーカスを変えるものではなく、テキストが Kody の内部プロンプトを改ざんするのを防ぐだけです。
  • 保存されない： リポジトリや組織の設定には何も書き込まれません。