Skip to main content
レビューディレクティブを使うと、その 1 回のレビューで Kody がどこを最も深く分析すべきかを指示できます。設定を変更する代わりに、レビューを起動するときに短い指示を添えます — 例えば「認証とセッションのロジックに集中して」— すると Kody は該当する変更コードに最も厳しい分析を集中させます。
ディレクティブは一時的です。その 1 回のレビュー実行にのみ適用され、設定には保存されず、今後のレビューには影響しません。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

アルファ — 申請制です。 Heavy mode はどの組織でもデフォルトではオフです。試したい場合は、 Discord または support@kodus.io から、あなたの組織で有効化するようご依頼ください。それまでフラグは受け付けられますが効果は ありません — 下記の提供状況を参照してください。
フォーカスディレクティブは Kody にどこを重点的に見るかを伝えます。--heavy はより長く見る ことを伝えます。finder が同じ diff に対して「見落としはないか？」という批評パスを追加で実行し、 レビューが遅くなり選別すべき候補が増える代わりに、実際の問題をより多く見つけます。
--heavy は行のどこに置いても構いません（フォーカステキストの前でも後でも）。いずれの場合も ディレクティブからは取り除かれるため、@kody review リトライ処理に注目 --heavy は 「リトライ処理に注目」にフォーカスします。
--force と併用するときは --force を先に置いてください。 --force はコマンド直後に ある場合のみ認識されます。そのため @kody review --force --heavy は強制の heavy レビューに なりますが、@kody review --heavy --force は強制されない heavy レビューになります。
ダッシュは必須です。ダッシュなしの heavy はディレクティブのテキストとして読まれるため、 @kody review heavy チェックアウト経路 はフラグを有効にせず「heavy チェックアウト経路」に フォーカスします。

​
提供状況

Heavy mode はアルファ機能です。明示的に有効化した組織でのみ実行されます：
フラグは静かにフォールバックします（エラーは出ません）。 組織が有効化されていない場合、 --heavy は受け付けられ、レビューは通常どおり実行されます — エラーも警告もなく、結果も 変わりません。アクセスを申請したのに有効かどうか判断できない場合は、推測せずご連絡ください。
アクセスをご希望の場合は、組織名を添えて Discord または support@kodus.io までご連絡ください。
見落としのコストが高い変更 — マイグレーション、認証の変更、決済経路 — で使ってください。 デフォルトにするものではありません。日常的な PR では、増えた候補はたいてい選別が必要な ノイズになります。

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

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

​
注意点と制限

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