メインコンテンツへスキップ

2 種類の Kody ルール

Kody ルールは 2 つのカテゴリに整理されており、設定のタブインターフェースで管理されます:
専用のコードレビューステージで実行される従来のコードレビュールール。ファイルの差分と PR メタデータを分析してコーディング標準を強制します。
  • ファイルレベルまたはプルリクエストレベルで適用
  • 変数、ファイル参照、MCP 関数をサポート
  • 自動コードレビュー時にトリガー

レビュールール

カスタムルールの作成

チームの正確なニーズに基づいてルールを定義します。レビュールールは ファイルレベルプルリクエストレベル の 2 つの異なるレベルで適用できます。両方のレベルで変数、ファイル参照、MCP 関数をサポートし、強力でコンテキスト対応のルールを構築できます。

変数、ファイル参照 & MCP 関数

ルールは変数、ファイル参照、MCP 関数を通じてリッチなコンテキストにアクセスできます。利用可能なものを以下に示します: 変数: 変数はルール実行時に利用可能なコンテキストデータを表します。利用可能なものを理解することで、変数と MCP 関数およびファイル参照を組み合わせてより優れたルールを作成できます。
  • ファイルレベル
    • fileDiff - 分析中の個別ファイルに対する特定の変更
  • PR レベル
    • pr_title - プルリクエストのタイトル
    • pr_description - プルリクエストの説明/本文
    • pr_total_additions - 追加された行の合計数
    • pr_total_deletions - 削除された行の合計数
    • pr_total_files - 変更されたファイルの合計数
    • pr_total_lines_changed - 変更された行の合計数
    • pr_files_diff - プルリクエスト全体のすべての変更の完全な差分
    • pr_tags - プルリクエストに関連するタグ
    • pr_author - プルリクエストの作者
    • pr_number - プルリクエスト番号
コンテキストデータにアクセスするためにルール指示でこれらの変数を使用し、追加情報を取得したり動的分析を実行するために MCP 関数と組み合わせます。 ファイル参照: コードの比較、パターンの検証、一貫性の強制、既存のテンプレートや標準の活用のために、ルール指示でファイルを直接参照します。
  • @file:path/to/file.ts - ルールを編集している同じリポジトリのファイルを参照
    • 現在のリポジトリ内のテンプレート、例、または設定ファイルを参照する場合に使用
    • 例:@file:src/services/userService.ts
  • @repo:org/project - 別のリポジトリのファイルを参照するか、リポジトリコンテキスト外でルールを設定する場合に使用
    • 複数のリポジトリ全体で一貫性を強制したり、共有標準を参照する場合に使用
    • 例:@repo:team/api-standards
ファイル参照の仕組み:
  • Kody はルールを保存するときにファイル参照を自動的に識別します
  • 参照はバックグラウンドで解決されます。完了を確認するためにエディタ横のステータスインジケーターを確認してください
  • プレースホルダーではなく正確な blob スタイルのパスを使用してください(例:src/utils/helpers.ts
  • ファイルの内容はルールコンテキストに注入され、Kody がパターンを比較、検証、または強制できます
  • ファイルレベルとプルリクエストレベルの両方のルールで機能します
MCP 関数: ルールエディタの @MCP ドロップダウンを通じて MCP(Model Context Protocol)関数にアクセスし、追加のデータとコンテキストを取得します。ワークスペースのプラグインページで接続された MCP ツールやサーバーを使用できます。 利用可能な関数には以下が含まれます:
  • リポジトリ操作:リポジトリのリスト、リポジトリファイル、コンテンツ、言語の取得
  • PR 分析:プルリクエストの詳細取得、コミットのリスト、PR ファイルコンテンツの分析
  • ファイルコンテンツの取得:ファイルコンテンツと差分の取得
  • クロスファイル検証:複数ファイルにわたる高度な分析
  • カスタム統合:プラグインとして接続された MCP サーバー(Jira、カスタムツールなど)
MCP 関数はルール評価時に実行され、現在のリポジトリ状態に適応してリアルタイムデータを取得するルールを可能にします。 ベストプラクティス:
  • 一般的なプレースホルダーではなく特定のファイルパスを使用する
  • チームの標準を表す安定したファイルを参照する
  • 解決エラーを避けるためにルールを保存する前にファイル参照が存在することをテストする
  • 包括的な検証のために変数、ファイル参照、MCP 関数を組み合わせる

ファイルレベルルール

特定のコードファイル内の問題を捕捉するために個別ファイルを分析します。 利用可能なコンテキスト: 詳細については上記の変数、ファイル参照 & MCP 関数セクションを参照してください。このレベルで利用可能:fileDiff 変数、ファイル参照(@file@repo)、MCP 関数。 できること:
  • @file または @repo を使用して参照ファイルと比較する
  • MCP 関数を使用して関連ファイルやリポジトリデータを取得する
  • 変数、ファイル参照、MCP 関数を組み合わせてパターンを検証し、一貫性を確認し、アーキテクチャルールを強制する
設定方法:
  • ルール名:ルールの目的を明確に定義する
  • ファイルパス:glob パターンを使用して特定のファイルまたはディレクトリにルールを制限する
  • 重大度:クリティカル、高、中、低に設定する
  • 詳細な指示fileDiff を使用し、@file/@repo でファイルを参照し、MCP 関数を呼び出してリッチなコンテキストで強力なルールを作成する
設定例: 📋 ルール:「ループ終了条件で等値演算子(==、!=)を使用しないこと。」 📁 パスsrc/**/*.ts ⚠️ 重大度:クリティカル 📝 指示:「等値演算子(== または !=)を使用すると、正確な値が一致しない場合に無限ループが発生する可能性があります。」 ❌ 悪い例:
// インクリメントが正確に 1 でない場合の無限ループのリスク
for (let i = 0; i != 10; i += 2) {
  console.log(i); // 0, 2, 4, 6, 8, 10, 12, 14... と永遠に出力される
}

// イテレーション中に配列が変更された場合のリスク
let items = [1, 2, 3, 4, 5];
for (let i = 0; i != items.length; i++) {
  if (items[i] === 3) {
    items.push(6); // 長さを変更し、無限ループを引き起こす可能性がある
  }
}
✅ 良い例:
// 安全:ループは常に終了する
for (let i = 0; i < 10; i += 2) {
  console.log(i); // 0, 2, 4, 6, 8 を出力して停止する
}

// 配列が変更されても安全
let items = [1, 2, 3, 4, 5];
for (let i = 0; i < items.length; i++) {
  if (items[i] === 3) {
    items.push(6); // ループは依然として安全に終了する
  }
}

プルリクエストレベルルール

クロスファイル検証と PR 固有の要件のためにプルリクエスト全体を分析します。 利用可能なコンテキスト: 詳細については上記の変数、ファイル参照 & MCP 関数セクションを参照してください。このレベルで利用可能:PR 変数(pr_titlepr_descriptionpr_files_diff など)、ファイル参照(@file@repo)、MCP 関数。 できること:
  • pr_titlepr_descriptionpr_author などの変数を使用して PR メタデータを検証する
  • @file または @repo を使用して設定ファイルやテンプレートを参照する
  • MCP 関数を使用して追加コンテキストを取得する(例:関連ファイルが存在するか確認、リポジトリ構造に対して検証)
  • PR 変数、ファイル参照、MCP 関数を組み合わせて包括的な検証ルールを作成する
設定方法: 作成プロセスはファイルレベルルールと同じですが、「プルリクエスト」スコープを選択する必要があります。この広いコンテキストにより、クロスファイルの依存関係と全体的な PR 品質の分析が可能になります。 例:
  • すべてのサービスファイルには対応するテストファイルが必要
  • PR の説明は完全で、追加または削除された内容を明確に述べる必要がある
  • コントローラーに新しいルートが作成された場合、routes.json に登録する必要がある
  • pr_total_lines_changed を使用してサイズ制限を超える PR をフラグする
  • pr_files_diff と MCP 関数を組み合わせてクロスファイルの依存関係を検証する
  • @file:routes.json を参照して新しいルートが登録されていることを確認する
  • MCP 関数を使用して変更されたサービスファイルにテストファイルが存在するか確認する

強力なルールの作成

変数、MCP 関数、ファイル参照を組み合わせて、リッチなコンテキストを持つ高度なルールを作成します。各レベルで利用可能なものを以下に示します: ファイルレベルの構成:
  • fileDiff を使用してファイルの特定の変更を分析する
  • @file:path/to/template.ts で関連ファイルを参照してパターンと比較する
  • MCP 関数を呼び出してリポジトリデータを取得したり、関連ファイルが存在するか確認する
  • :「fileDiff を分析し、@file:src/utils/example.ts のパターンに従っているか確認します。MCP を使用して関連するテストファイルが存在するか検証します。」
PR レベルの構成:
  • PR 変数(pr_titlepr_descriptionpr_files_diff など)を使用して PR メタデータとサイズを検証する
  • @file:config.json または @repo:org/shared-config で設定ファイルを参照して一貫性を強制する
  • MCP 関数を呼び出してクロスファイル検証を実行したり、リポジトリ構造を確認したり、コミット履歴を取得する
  • :「pr_files_diff に新しいルートが含まれている場合、@file:routes.json に登録されていることを確認します。MCP を使用して変更されたすべてのサービスファイルに対応するテストファイルが存在するか確認します。」
クロスリポジトリの検証:
  • @repo:org/project で他のリポジトリのファイルを参照してプロジェクト全体の一貫性を維持する
  • MCP 関数と組み合わせて共有標準やテンプレートと照合して検証する
  • :「@repo:org/api-standards で定義されたパターンに API エンドポイントが従っていることを確認します。MCP を使用して最新の標準ドキュメントを取得します。」
動的分析:
  • MCP 関数はルール評価時に実行され、現在のリポジトリ状態に適応するルールを可能にする
  • ファイル、コミット、リポジトリ構造についてリアルタイムデータを取得する
  • :「MCP を使用して現在のリポジトリ構造を確認し、新しいファイルが既存のディレクトリパターンに従っていることを確認します。」
この構成により、コードの変更だけでなく、コードベース、チームの実践、プロジェクト要件のより広いコンテキストを理解するルールが作成できます。

ルールライブラリからインポート

実証済みのベストプラクティスを即座に活用します:
  • Kodus ダッシュボードのディスカバリールールに移動します。
  • 重大度、言語、またはタグでルールをフィルタリングします。
  • ワンクリックでルールをインポートして有効化します。
例:
  • セキュリティ:「安全でない MD5 ハッシングの使用を禁止する。」
  • 保守性:「React コンポーネントを 150 行未満に制限する。」

メモリ

メモリは、Kody がチームの会話とコーディング実践から学習する永続的なコンテキスト指示です。コードレビュー中に実行されるレビュールールとは異なり、メモリはすべてのプロンプトと会話に注入されて継続的な高優先度コンテキストを提供します。

メモリの仕組み

  • どこにでも注入:メモリはコードレビュー分析(クロスファイル、セーフガード、PR レベルルール)と会話でのインタラクションに含まれます
  • 高優先度コンテキスト:メモリは AI によって高優先度のガイダンスとして扱われ、チームの規約が一貫して適用されます
  • インテリジェントな重複排除:新しいメモリが作成されると、Kody は LLM ベースの解決メカニズムを使用して作成するか、スキップするか(重複の場合)、既存のメモリを更新するかを決定します

メモリの作成

メモリを作成する方法は 2 つあります:

会話経由

メモリを作成する最も自然な方法は、PR コメントで Kody との会話を通じてです。Kody は規約を保存する明示的および暗黙的な意図の両方を検出します: 明示的 — Kody に記憶を依頼する:
@kody remember: API ペイロードキーは camelCase、データベースカラムは snake_case です。
@kody please remember: ドメイン層では、エンティティはデフォルトで null 可能なプロパティを持ってはいけません。
暗黙的 — Kody が捉える設定や規約を述べる:
@kody このリポジトリでは Lodash を避け、読みやすさとバンドルサイズのためにネイティブ JS の配列メソッドを好みます。
@kody Postgres での存在確認には、パフォーマンスのために COUNT(*) や広い LEFT JOIN パターンより EXISTS を好みます。
@kody AWS SDK v2 から v3 に移行中です。新しい v2 インポートはブロッカーとして扱ってください。
Kody は一時的な指示(例:「今これを修正して」)、デバッグのやり取り、質問、曖昧な発言、または単一のタスクや PR に明示的にスコープされたリクエストに対してはメモリを作成しません。
メモリが作成または更新されると、Kody は確認を応答し、UI でメモリを表示するための直接リンクを提供します。

UI 経由

メモリを手動で作成することもできます:
  1. コードレビュー設定リポジトリKody ルールに移動します
  2. メモリタブに切り替えます
  3. メモリを追加をクリックして新しいエントリを作成します
  4. メモリのコンテンツとスコープを入力します

メモリのスコープ

各メモリには適用先を決定するスコープがあります:
スコープ説明
ディレクトリリポジトリ内の glob パターンに一致するファイルに適用src/components/uisrc/**/*.ts
リポジトリリポジトリ全体に適用リポジトリ内のすべてのファイル
組織組織内のすべてのリポジトリに適用組織内のすべてのリポジトリ

LLM 生成メモリの承認

デフォルトでは、AI 生成のメモリは自動的に有効化されます。有効になる前に手動承認を要求できます:
  1. コードレビュー設定リポジトリKody ルールメモリタブに移動します
  2. LLM 生成メモリの承認を有効にします
有効にすると:
  • AI 生成のメモリは保留状態に入り、承認されるまで有効化されません
  • 保留中のメモリ数を示す通知バッジが表示されます
  • 保留中のメモリをクリックして、保留中のアイテムを確認、承認、破棄、または変換します
  • 新しいメモリの作成と既存のメモリの更新の両方が承認フローを通じます
kodus-config.yml でも設定できます:
llmGeneratedMemoriesRequireApproval: true

保留中のメモリのレビュー

保留中のメモリモーダルは 2 つのカテゴリを示します:
  • 新しいメモリ:承認待ちの AI 生成メモリ
  • メモリの更新:既存のメモリへの提案された変更
各保留中のアイテムに対して:
  • 適用:メモリを有効化するか更新を適用する
  • 破棄:メモリまたは更新を拒否する
  • レビュールールに変換:メモリを標準のレビュールールに変換する

次のステップ

IDE ルールの同期

Cursor、Copilot、Claude および他の AI コーディングツールからルールを自動インポートします。

リポジトリルール

構造化されたマークダウンファイルを使用してリポジトリに直接ルールを作成します。

AI 生成

コードベースのパターンと過去のレビューに基づいて AI がルールを生成します。