概要

​

Kody ルール UI の 2 つの種類

​

レビュールール

​

カスタムルールの作成

​

変数、ファイル参照 & 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 - プルリクエスト番号

• @file:path/to/file.ts - ルールを編集している同じリポジトリのファイルを参照
  • 現在のリポジトリ内のテンプレート、例、または設定ファイルを参照する場合に使用
  • 例：@file:src/services/userService.ts
• @repo:org/project - 別のリポジトリのファイルを参照するか、リポジトリコンテキスト外でルールを設定する場合に使用
  • 複数のリポジトリ全体で一貫性を強制したり、共有標準を参照する場合に使用
  • 例：@repo:team/api-standards

• Kody はルールを保存するときにファイル参照を自動的に識別します
• 参照はバックグラウンドで解決されます。完了を確認するためにエディタ横のステータスインジケーターを確認してください
• プレースホルダーではなく正確な blob スタイルのパスを使用してください（例：src/utils/helpers.ts）
• ファイルの内容はルールコンテキストに注入され、Kody がパターンを比較、検証、または強制できます
• ファイルレベルとプルリクエストレベルの両方のルールで機能します

• リポジトリ操作：リポジトリのリスト、リポジトリファイル、コンテンツ、言語の取得
• PR 分析：プルリクエストの詳細取得、コミットのリスト、PR ファイルコンテンツの分析
• ファイルコンテンツの取得：ファイルコンテンツと差分の取得
• クロスファイル検証：複数ファイルにわたる高度な分析
• カスタム統合：プラグインとして接続された MCP サーバー（Jira、カスタムツールなど）

• 一般的なプレースホルダーではなく特定のファイルパスを使用する
• チームの標準を表す安定したファイルを参照する
• 解決エラーを避けるためにルールを保存する前にファイル参照が存在することをテストする
• 包括的な検証のために変数、ファイル参照、MCP 関数を組み合わせる

​

ファイルレベルルール

• @file または @repo を使用して参照ファイルと比較する
• MCP 関数を使用して関連ファイルやリポジトリデータを取得する
• 変数、ファイル参照、MCP 関数を組み合わせてパターンを検証し、一貫性を確認し、アーキテクチャルールを強制する

• ルール名：ルールの目的を明確に定義する
• Execution mode：Per file（デフォルト）
• Path：glob パターンを使用して特定のファイルまたはディレクトリにルールを制限する（空のままにするとすべてのファイルに適用）
• Instructions：fileDiff を使用し、@file/@repo でファイルを参照し、MCP 関数を呼び出してリッチなコンテキストで強力なルールを作成する。新しいルールは Start with a popular template から始めることもできます
• Severity：Critical、High（デフォルト）、Medium、Low に設定する
• Advanced settings：Inheritable（デフォルトでオン。ルール継承を参照）と Code examples（Bad example / Good example）

// インクリメントが正確に 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_title、pr_description、pr_author などの変数を使用して PR メタデータを検証する
• @file または @repo を使用して設定ファイルやテンプレートを参照する
• MCP 関数を使用して追加コンテキストを取得する（例：関連ファイルが存在するか確認、リポジトリ構造に対して検証）
• PR 変数、ファイル参照、MCP 関数を組み合わせて包括的な検証ルールを作成する

• すべてのサービスファイルには対応するテストファイルが必要
• PR の説明は完全で、追加または削除された内容を明確に述べる必要がある
• コントローラーに新しいルートが作成された場合、routes.json に登録する必要がある
• pr_total_lines_changed を使用してサイズ制限を超える PR をフラグする
• pr_files_diff と MCP 関数を組み合わせてクロスファイルの依存関係を検証する
• @file:routes.json を参照して新しいルートが登録されていることを確認する
• MCP 関数を使用して変更されたサービスファイルにテストファイルが存在するか確認する

​

強力なルールの作成

• fileDiff を使用してファイルの特定の変更を分析する
• @file:path/to/template.ts で関連ファイルを参照してパターンと比較する
• MCP 関数を呼び出してリポジトリデータを取得したり、関連ファイルが存在するか確認する
• 例：「fileDiff を分析し、@file:src/utils/example.ts のパターンに従っているか確認します。MCP を使用して関連するテストファイルが存在するか検証します。」

• PR 変数（pr_title、pr_description、pr_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 を使用して現在のリポジトリ構造を確認し、新しいファイルが既存のディレクトリパターンに従っていることを確認します。」

​

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

• Code review → Kody Rules（Review Rules タブ）で Discovery をクリックすると、ルールライブラリ（Rules Marketplace）が開きます。ルールのリストが空の場合は Browse the library から、または ⌘K コマンドパレットで Rules library を検索して開くこともできます。
• Featured から始めるか、Browse に切り替えてカタログ全体を検索し、Severity、Language、Packs でルールをフィルタリングします。
• ルールを開いて Add to my rules をクリックします。その横のリポジトリピッカーで、Global か、ルールを適用するリポジトリ（およびディレクトリ）を選択します。

• セキュリティ：「安全でない MD5 ハッシングの使用を禁止する。」
• 保守性：「React コンポーネントを 150 行未満に制限する。」

​

メモリ

​

メモリの仕組み

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

​

メモリの作成

​

会話経由

@kody remember: このリポジトリはサードパーティ API を反映しているため、一部の payload フィールドは意図的に snake_case のままです。

@kody please remember: このサービスはヘキサゴナルアーキテクチャを採用し、adapter は境界に置きます。

@kody このリポジトリはサードパーティ API を反映しているため、一部の payload フィールドは意図的に snake_case のままです。

@kody このサービスでは、テストは中央の test フォルダではなく実装ファイルの近くに置くことが多いです。

@kody 課金モジュールは移行の途中なので、大きなリファクタではなく段階的な変更を優先してください。

​

UI 経由

1. サイドバーで、Code review グループ上部のスコープピッカーで Global（またはリポジトリ／ディレクトリ）を選択し、Kody Rules を開きます。メモリはここで選択したスコープに作成されます
2. Memories タブに切り替えます
3. New memory（リストが空の場合は Add a memory）をクリックします
4. Memory name と Instructions を入力し、Create memory をクリックします

​

メモリのスコープ

​

LLM 生成メモリの承認

1. 目的のスコープ（Global、リポジトリ、またはディレクトリ）で Code review → Kody Rules に移動します
2. Configuration をクリックしてサイドシートを開きます
3. Kody knowledge approval を有効にします

• AI 生成のルールとメモリは保留状態に入り、承認されるまで有効化されません
• Review Rules タブと Memories タブのバッジに保留中の件数が表示されます
• 保留中のアイテムはページ上部の Pending review セクションに表示され、そこで承認または破棄します（下記の保留中のレビューを参照）
• 新規作成と既存のルール／メモリの更新の両方が承認フローを通じます

kodyKnowledgeApproval:
    enabled: true

​

保留中のレビュー

• 新しいルールとメモリ：承認待ちの AI 生成アイテム。Approve を選ぶとアイテムが有効化され、Discard を選ぶと拒否されます。
• 更新：既存のルールまたはメモリへの提案された変更で、差分として表示されます。Update existing で変更を適用し、Create new instead で元のものを残したまま提案を別のアイテムとして追加し、Discard で拒否します。

​

次のステップ