How open-code-review Supports Different Programming Languages: Rule-Based Architecture Explained

open-code-review supports multiple programming languages by detecting file extensions, loading language-specific rule definitions from Markdown files in internal/config/rules/rule_docs/, and injecting those contextual guidelines into LLM prompts to generate precise, idiomatic code reviews.

The alibaba/open-code-review repository implements a language-agnostic core that adapts to diverse programming ecosystems without hardcoding language logic. Instead, it leverages a modular rule system where each language's best practices, anti-patterns, and severity guidelines are defined in standalone Markdown documents. This design enables the system to review everything from mainstream languages like Go and Python to specialized formats like Terraform and Protobuf through simple configuration files.

Language Detection and Rule Loading Architecture

The system employs a two-phase approach to language support: automatic detection via file metadata followed by dynamic rule retrieval from the embedded filesystem.

File Extension Detection

When processing a pull request, open-code-review scans changed files and maps extensions to language identifiers using an internal detection map. The system recognizes standard extensions such as .go, .py, .java, .cpp, .rs, .php, .kt, .js, .ts, .tf, and .proto, routing each file to its corresponding rule set without requiring explicit language declarations.

Loading Rule Documents from internal/config/rules/rule_docs/

Language-specific guidelines reside as Markdown files in internal/config/rules/rule_docs/. The core engine utilizes file system operations such as os.ReadFile to load these documents at runtime. For example, when reviewing a Python file, the system loads internal/config/rules/rule_docs/python.md, which contains concrete patterns like "avoid mutable default arguments" and "detect unused imports."

How Language-Specific Rules Power the LLM Review Process

Once loaded, the rule content becomes part of the prompt engineering strategy that guides the LLM's analysis, ensuring reviews respect language idioms.

Prompt Construction in main_task_user.md

The base prompt template located at internal/config/template/prompts/main_task_user.md receives the language-specific rule text as a dynamic variable. The system concatenates the base instructions with the loaded rule document, creating a contextualized prompt that instructs the model to apply language-aware checks. This ensures the LLM understands Pythonic conventions when reviewing .py files and Go idioms when reviewing .go files.

The Review Filter Task

Additional prompt templates such as internal/config/template/prompts/review_filter_task_user.md incorporate language context to filter and prioritize findings. By embedding the same rule documents into filtering stages, the system maintains consistency between detection and validation logic across all supported languages.

Supported Languages and Rule Files

The repository includes comprehensive rule documentation for over a dozen programming languages and configuration formats:

Language	Rule Document Path
C++	internal/config/rules/rule_docs/cpp.md
Go	internal/config/rules/rule_docs/go.md
Java	internal/config/rules/rule_docs/java.md
Kotlin	internal/config/rules/rule_docs/kotlin.md
Python	internal/config/rules/rule_docs/python.md
Rust	internal/config/rules/rule_docs/rust.md
PHP	internal/config/rules/rule_docs/php.md
JavaScript/TypeScript	internal/config/rules/rule_docs/package_json.md
JSON	internal/config/rules/rule_docs/json.md
GraphQL	internal/config/rules/rule_docs/graphql.md
Terraform	internal/config/rules/rule_docs/terraform.md
Protobuf	internal/config/rules/rule_docs/protobuf.md
Julia	internal/config/rules/rule_docs/julia.md
Haskell	internal/config/rules/rule_docs/haskell.md
Nix	internal/config/rules/rule_docs/nix.md
Bicep	internal/config/rules/rule_docs/bicep.md
Astro	internal/config/rules/rule_docs/astro.md

Extending Support for New Languages

Adding support for a new language requires no changes to the core engine. Create a Markdown file in internal/config/rules/rule_docs/ following the existing pattern, then ensure the extension map includes the new file type.

For example, to add Swift support:

1. Create internal/config/rules/rule_docs/swift.md containing Swift-specific guidelines and anti-patterns.
2. Add the extension mapping ".swift": "swift" to the language detection configuration.

The engine automatically discovers and loads the new rules on the next execution cycle.

// Detect language from file extension
lang := detectLanguage(file.Path)

// Load the language-specific rule markdown
rulePath := fmt.Sprintf("internal/config/rules/rule_docs/%s.md", lang)
rules, err := os.ReadFile(rulePath)
if err != nil {
    return fmt.Errorf("failed to load rules for %s: %w", lang, err)
}

// Construct the LLM prompt with injected language context
prompt := fmt.Sprintf("%s\n\nLanguage-specific rules:\n%s", basePromptTemplate, string(rules))
response := llm.GenerateReview(prompt)

Summary

• open-code-review uses file extension detection to identify programming languages in pull requests.
• Language-specific rules are stored as Markdown documents in internal/config/rules/rule_docs/.
• The system dynamically loads these rules using standard file I/O operations like os.ReadFile.
• Rules are injected into LLM prompts via templates such as main_task_user.md and review_filter_task_user.md.
• New language support requires only adding a rule file and extension mapping, making the architecture fully extensible without core code modifications.

Frequently Asked Questions

What programming languages does open-code-review support out of the box?

The system includes rule definitions for C++, Go, Java, Kotlin, Python, Rust, PHP, JavaScript, TypeScript, JSON, GraphQL, Terraform, Protobuf, Julia, Haskell, Nix, Bicep, and Astro. The modular structure allows immediate support for additional languages by adding new Markdown files to the rules directory.

How does open-code-review detect the programming language of a file?

The system maps file extensions to language identifiers using an internal extension-to-language dictionary. When processing a pull request, it examines the paths of changed files (e.g., .py for Python, .go for Go) and routes them to the corresponding rule set located in internal/config/rules/rule_docs/.

Can I add custom rules for a specific language?

Yes. Since language rules are plain Markdown files in internal/config/rules/rule_docs/, you can modify existing files or create new ones with custom patterns, severity levels, and best practices. The core engine will automatically load these changes without requiring recompilation or service restarts.

Where are the language-specific rules stored in the repository?

All language rule definitions are located in the internal/config/rules/rule_docs/ directory, with each language represented by a separate .md file named after the language identifier (e.g., python.md, go.md, cpp.md).

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}