Overview

​

Two Types of Kody Rules

​

Review Rules

​

Create Custom Rules

​

Variables, File References & MCP Functions

• File-Level:
  • fileDiff - The specific changes made to the individual file being analyzed
• PR-Level:
  • pr_title - The title of the Pull Request
  • pr_description - The description/body of the Pull Request
  • pr_total_additions - Total number of lines added
  • pr_total_deletions - Total number of lines deleted
  • pr_total_files - Total number of files changed
  • pr_total_lines_changed - Total number of lines modified
  • pr_files_diff - Complete diff of all changes across the entire Pull Request
  • pr_tags - Tags associated with the Pull Request
  • pr_author - Author of the Pull Request
  • pr_number - Pull Request number

• @file:path/to/file.ts - Reference files in the same repository where you’re editing the rule
  • Use when referencing templates, examples, or configuration files within your current repository
  • Example: @file:src/services/userService.ts
• @repo:org/project - Reference files in another repository or when configuring rules outside a repo context
  • Use when enforcing consistency across multiple repositories or referencing shared standards
  • Example: @repo:team/api-standards

• Kody identifies file references automatically when you save a rule
• References are resolved in the background—watch the status indicator next to the editor to confirm completion
• Use accurate blob-style paths (e.g., src/utils/helpers.ts) instead of placeholders
• File contents are injected into the rule context, allowing Kody to compare, validate, or enforce patterns
• Works in both File-Level and Pull Request-Level rules

• Repository operations: List repositories, get repository files, content, and languages
• PR analysis: Get pull request details, list commits, analyze PR file content
• File content retrieval: Fetch file contents and diffs
• Cross-file validation: Perform advanced analysis across multiple files
• Custom integrations: Any MCP server you’ve connected as a plugin (Jira, custom tools, etc.)

• Use specific file paths rather than generic placeholders
• Reference stable files that represent your team’s standards
• Test file references exist before saving rules to avoid resolution errors
• Combine variables, file references, and MCP functions for comprehensive validation

​

File-Level Rules

• Compare against reference files using @file or @repo
• Fetch related files or repository data using MCP functions
• Combine variables, file references, and MCP functions to validate patterns, check consistency, or enforce architectural rules

• Rule name: Clearly define the rule purpose
• File Paths: Limit rules to specific files or directories using glob patterns
• Severity: Set to Critical, High, Medium, or Low
• Detailed Instructions: Use fileDiff, reference files with @file/@repo, and call MCP functions to compose powerful rules with rich context

// Risk of infinite loop if increment is not exactly 1
for (let i = 0; i != 10; i += 2) {
  console.log(i); // Will print 0, 2, 4, 6, 8, 10, 12, 14... forever
}

// Risk if array is modified during iteration
let items = [1, 2, 3, 4, 5];
for (let i = 0; i != items.length; i++) {
  if (items[i] === 3) {
    items.push(6); // Modifies length, can cause infinite loop
  }
}

// Safe: loop will always terminate
for (let i = 0; i < 10; i += 2) {
  console.log(i); // Will print 0, 2, 4, 6, 8 and stop
}

// Safe even if array is modified
let items = [1, 2, 3, 4, 5];
for (let i = 0; i < items.length; i++) {
  if (items[i] === 3) {
    items.push(6); // Loop will still terminate safely
  }
}

​

Pull Request-Level Rules

• Validate PR metadata using variables like pr_title, pr_description, pr_author
• Reference configuration files or templates using @file or @repo
• Fetch additional context using MCP functions (e.g., check if related files exist, validate against repository structure)
• Combine PR variables, file references, and MCP functions to create comprehensive validation rules

• Every service file must have a corresponding test file
• PR description must be complete, clearly stating what was added or removed
• When a new route is created in a controller, it must be registered in routes.json
• Use pr_total_lines_changed to flag PRs exceeding size limits
• Combine pr_files_diff with MCP functions to validate cross-file dependencies
• Reference @file:routes.json to ensure new routes are registered
• Use MCP functions to check if test files exist for modified service files

​

Composing Powerful Rules

• Use fileDiff to analyze the specific changes in a file
• Reference related files with @file:path/to/template.ts to compare against patterns
• Call MCP functions to fetch repository data or check if related files exist
• Example: “Analyze fileDiff and ensure it follows the pattern in @file:src/utils/example.ts. Use MCP to verify related test files exist.”

• Use PR variables (pr_title, pr_description, pr_files_diff, etc.) to validate PR metadata and size
• Reference configuration files with @file:config.json or @repo:org/shared-config to enforce consistency
• Call MCP functions to perform cross-file validation, check repository structure, or fetch commit history
• Example: “If pr_files_diff contains new routes, verify they’re registered in @file:routes.json. Use MCP to check if corresponding test files exist for all modified service files.”

• Reference files from other repositories with @repo:org/project to maintain consistency across projects
• Combine with MCP functions to validate against shared standards or templates
• Example: “Ensure API endpoints follow the pattern defined in @repo:org/api-standards. Use MCP to fetch the latest standards document.”

• MCP functions execute during rule evaluation, enabling rules that adapt to current repository state
• Fetch real-time data about files, commits, or repository structure
• Example: “Use MCP to check the current repository structure and ensure new files follow the existing directory patterns.”

​

Import from Rules Library

• Navigate to Discovery Rules in your Kodus dashboard.
• Filter rules by severity, language, or tags.
• Import and activate rules with a single click.

• Security: “Disallow use of insecure MD5 hashing.”
• Maintainability: “Limit React components to less than 150 lines.”

​

Memories

​

How Memories Work

• Injected everywhere: Memories are included in code review analysis (cross-file, safeguards, PR-level rules) and in conversational interactions
• High-priority context: Memories are treated as high-priority guidance by the AI, ensuring your team’s conventions are consistently applied
• Intelligent deduplication: When a new memory is created, Kody uses an LLM-based resolution mechanism to determine whether to create it, skip it (if duplicate), or update an existing memory

​

Creating Memories

​

Via Conversation

@kody remember: API payload keys are camelCase, database columns are snake_case.

@kody please remember: in the domain layer, entities must never have nullable properties by default.

@kody in this repo we avoid Lodash and prefer native JS array methods for readability and bundle size.

@kody for existence checks in Postgres we prefer EXISTS over COUNT(*) and over broad LEFT JOIN patterns for performance.

@kody we're migrating from AWS SDK v2 to v3; treat any new v2 import as blocker.

​

Via the UI

1. Go to Code Review Settings → Repository → Kody Rules
2. Switch to the Memories tab
3. Click Add Memory to create a new entry
4. Fill in the memory content and scope

​

Memory Scopes

​

LLM-Generated Memories Approval

1. Go to Code Review Settings → Repository → Kody Rules → Memories tab
2. Enable LLM-generated memories approval

• AI-generated memories enter a pending state and are not active until approved
• A notification badge appears showing pending memories count
• Click Pending Memories to review, approve, discard, or convert pending items
• Both new memory creations and updates to existing memories go through the approval flow

llmGeneratedMemoriesRequireApproval: true

​

Pending Memories Review

• New Memories: AI-generated memories waiting for approval
• Memory Updates: Proposed changes to existing memories

• Apply: Activate the memory or apply the update
• Discard: Reject the memory or update
• Convert to Review Rule: Transform a memory into a standard Review Rule

​

Next Steps