Setting Up Kody Rules for Code Reviews

The Kody Rules are like internal laws for your repository. They allow Kody to automatically enforce coding standards, security, and best practices during code review. These rules can range from naming conventions, such as React components must be in PascalCase, to critical business requirements, such as payment operations must be idempotent. By creating clear rules, you reduce inconsistencies, speed up reviews, and prevent recurring issues from happening again. If your team already follows well-defined standards, Kody Rules ensure they are applied consistently. If there is no formal standard yet, the Rules Library can be the starting point to create one.

Accessing the Kody Rules Panel

To view, create, or edit rules:

1. Go to the Kodus panel → Code Review Settings → Kody Rules.

If this is your first time accessing it, you will see some rules automatically created by Kody. They are a good starting point, but the real value is in creating or importing rules specific to your context. 💡 Why this matters: starting with the right rules from the beginning of the trial helps Kody provide relevant feedback right from the first PRs.

Creating a Custom Rule

When you click on New Rule, you need to choose the scope:

• File: for rules that apply to specific files or folders.
• Pull Request: for rules that apply to the PR as a whole, including title, description, and the set of changes. In this case, the Path field is disabled because the rule is not focused on specific files.

💡 Quick tip: If the rule is about what is being changed → File. If it is about how the change is being made → Pull Request.

Instructions

The Instructions field is where you clearly and objectively describe what Kody should look for during code review. This is where you translate the standard your team wants to follow into text that Kody can interpret and apply consistently. A good instruction should:

• Explain what needs to be done or avoided.
• Include relevant technical details.
• Be short and direct so that anyone on the team understands it without needing additional context.

💡 The more specific it is, the more accurate Kody’s detection will be, and the clearer the comment in the PR will appear. For example: This description makes the purpose of the rule clear (avoiding duplicate charges) and the technique to be applied (using idempotency keys), allowing both Kody and the developer to understand the reason behind the check.

Choosing the Rule Severity

Severity defines the priority of this rule during code review and how likely it is to appear for the developer. More severe rules tend to be displayed more prominently and more frequently. Use the following logic to decide:

• Low: minimal impact, only for subtle or stylistic recommendations.
• Medium: moderate importance, when the practice is desired but not critical.
• High: high priority, should appear frequently when the violation occurs.
• Critical: maximum priority, used for issues that can cause severe failures, security risks, or direct business impact.

💡 If no severity is chosen, the default is High.

Including Good and Bad Examples

Kody understands your rules better when you provide both a Bad Example and a Good Example. This avoids ambiguous interpretations and improves the quality of suggestions. 📌 Example 💡 Important: use examples that are close to your real code. This helps Kody be more accurate and your team understand faster.

Using the Rules Library

The Rules Library is a collection of ready-made rules that Kody provides to apply to your repository with a single click. These are best practices tested and validated by other teams, covering everything from coding standards to security, performance, and maintainability rules. It is a great starting point if your team does not yet have defined best practices because it helps create that foundation without starting from scratch. And if your team already follows standards, the library can complement them with new ideas and reinforce areas that might not be formalized yet. How it works:

1. In the Kodus panel, go to Discovery Rules.
2. Filter by severity, language, or tags to find what makes sense for your context.
3. Open the rule to see details, instructions, and examples.
4. Like it? Activate it with one click and Kody will start applying it to your PRs.

Examples of what you will find:

• Security: “Prohibit use of insecure MD5 hash.”
• Maintainability: “Limit React components to fewer than 150 lines.”

Even if your team already follows defined standards, it is always worth taking a look. It is common to find rule ideas that further strengthen your review process.