> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qodo.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Generate and manage rules
> This page explains how to generate and manage rules in the Qodo portal, including rule lifecycle operations such as editing, disabling, and deletion.
export const AzureIcon = () => ;
BetaGitHubGitLabBitbucket CloudAzure DevOps
**Who can view and manage rules?**
* **Admins** can create, edit, enable, approve, and delete rules.
* **Members** can generate rules in the portal. However, these rules appear in the **Pending rules** tab and require admin approval before becoming active. Members can also view active rules, pending rules, and review rule outcomes during code reviews.
## View your rules
In the Qodo portal, navigate to **Review Standards** from the left menu.
The summary cards at the top show rule performance for the last 30 days. See [Rule analytics](/governance/rule-enforcement/analytics) for details.
## Change how rules are grouped
Use the grouping controls above the table to change how rules are organized:
| Grouping | What it shows |
| - | - |
| **Origin repo** | Grouped by where each rule comes from: its repository, then its source file. |
| **List** | Every rule in one flat list, with no grouping. |
## Anatomy of a rule
A rule consists of the following fields:
| Field | Description | Details |
| - | - | - |
| **Rule name** | Short, descriptive title summarizing the rule’s intent. | Shown in the table in the **Rules** tab and in code review findings. |
| **Rule content** | Enforcement description used during reviews. | Explains what to check and what behavior is expected. |
| **Examples** | Compliant and non-compliant code examples. | Displayed to developers when violations occur. |
| **Category** | Type of issue the rule addresses. | Security, Correctness, Quality, Reliability, Performance, Testability, Compliance, Accessibility, Observability, Architecture. |
| **Severity** | Priority level of a violation. | Error (action required), Warning (recommended), Recommendation (informational). |
| **Scope** | Where the rule is enforced. | **Global** by default, applying organization-wide, or limited to specific Git organizations, repositories, and optional path patterns. |
| **Source type** | The category of origin: how this rule was created or added. | User, Repository File, Qodo Library, Mined Pattern, Compliance File |
| **Source** | The exact location the rule came from. | A file path, URL, or identifier pointing to the original source. For a rule mined from the same pattern across multiple pull requests, shows the pull request count instead, linking to each contributing pull request. |
**Rule scope**
Scope defines where the rule is enforced. You can narrow the scope to limit enforcement:
* **Global** (default): applies the rule to all repositories across all Git organizations.
* **Git organization**: applies the rule to selected Git organizations.
* **Repository**: applies only to selected repositories.
* **Path patterns**: applies to specific directories or files within a repository. Path patterns are optional and can only be added after selecting a repository, and are especially useful for monorepos where different projects or services live under the same repository.
Rules extracted from supported files (such as AGENTS.md) are automatically scoped to the folder containing that file, with no additional portal configuration needed.
Scope can be edited for a single rule at a time from the rule's side panel (see [Edit rule](#manage-existing-rules)), or for multiple rules at once (see [Manage rules in bulk](#manage-rules-in-bulk)).
## Generate a rule
Use this flow to describe a rule in natural language and let Qodo agent generate a structured draft.
1. From **Rules**, click **Generate**.
2. Enter a short description of the rule’s intent.
3. Click **Generate rule**.
Example prompts:
* "Disallow `console.log` in production builds"
* "Avoid SQL string concatenation with user input"
Qodo generates a complete rule draft that can be edited before activation.
Before activation, Qodo checks for:
* Conflicts
* Duplicates
* Overlapping scope
You can review related rules or revise the draft.
The rule is added to the table in the **Rules** tab and enforced automatically according to its defined scope (repositories and optional path patterns).
If you are a member (non-admin), your rule appears in the **Pending rules** tab for admin review before activation, unless an admin has enabled [**Auto-approve user suggestions**](/configuration/context#review-standards). See [Review and activate pending rules](/governance/rule-enforcement/suggested-rules).
## Manage existing rules
Management actions for existing rules are available from the **actions menu (⋮)** in the table in the **Rules** tab. These actions are optional and can be performed at any time by admins or team admins.
To open the rule behind a specific finding, click the rule link in the finding's Evidence section in the pull request. See [Anatomy of a Qodo Code Review](/code-review/comment-anatomy#unpack-a-code-review-finding).
| Action | Description |
| - | - |
| Edit rule | Update the rule name, content, examples, scope, or severity from the rule's side panel. |
| Deactivate or Activate | Pauses enforcement while retaining the rule and its history. |
| Delete rule | Permanently removes the rule. This cannot be undone. |
## Manage rules in bulk
Multiple rules can be activated, deactivated, or rescoped at once from the **Rules** tab.
Select the checkbox next to each rule, or select the checkbox in the table's top row to select every rule at once.
* **Activate** or **Deactivate**: Update the enabled state for all selected rules.
* **Define scope**: Set the scope for all selected rules at once. Select **Global** to apply the selected rules organization-wide, or **Specific repositories** to select a total of 25 entities (organizations and repositories), with an optional path pattern for each selected repository. See [Rule scope](#anatomy-of-a-rule) for more details on scopes.
A confirmation dialog appears before the action is applied. Confirm to apply the change to all selected rules.
Defining a scope in bulk replaces the current scope on every selected rule. This cannot be undone.
## Automatic rule updates from files
Qodo continuously monitors files that have already been imported. When changes are merged to one of these files, Qodo processes them and automatically updates the Review Standards to reflect the file's current contents. The scope of extracted rules is automatically determined by the file's location in the repository.
If a new supported file is added to a repository after that repository was imported, Qodo doesn't detect it automatically. Re-import the repository from **Import rules and skills** to pick it up.
New rules extracted from supported files are:
* Added directly as active rules.
* Enriched with category, severity, scope, and examples.
Only new rules are added this way. Changes to or deletions of existing rules in these files aren't reflected. Manage those directly from the **Rules** tab.
**Single-tenant customers**
If you installed Qodo before the new setup wizard was introduced, your GitHub App may not have the Push event subscription enabled. Without it, Qodo cannot detect changes to supported rule files.
To enable it:
1. Go to your GitHub App settings page.
2. Select **Permissions & events**.
3. Scroll to **Subscribe to events**.
4. Check **Push**.
5. Click **Save changes**.
For more details, see [GitHub's documentation](https://docs.github.com/en/apps/maintaining-github-apps/modifying-a-github-app-registration).
## Fetch rules using `get-qodo-rules` skill
Supported AI coding agents can access your Review Standards directly using the `get-qodo-rules` skill.
The skill fetches repository specific rules from the Qodo platform API, including organization, repository, and path-level rules, and loads them into the agent context. This allows the agent to reference the same rules that are defined in Qodo.
This capability is optional and does not replace Qodo’s rule enforcement. It enables agents to use the rules already configured for the repository. Using the skill requires a Qodo API key and rules configured in the Qodo platform.
For more information, see:
* To set up the Rules Skill, see the [open-source installation instructions](https://github.com/qodo-ai/qodo-skills).
* For an overview on Qodo Agent Skills, see [Agent Skills](/agent-skills).
## Troubleshoot rules and skills import
Check rules and skills import progress and fix import problems from **Background activity** in the top-right corner of the portal. For more information, see [Troubleshoot background processes](/governance/troubleshoot-background-processes).
## Next steps
* [Best practices for setting rules](/governance/rule-enforcement/best-practices-for-setting-rules): Get guidance on writing clear, impactful, and maintainable rules.
* [Rule analytics](/governance/rule-enforcement/analytics): Track how rules perform across pull requests over time.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.
The summary cards at the top show rule performance for the last 30 days. See [Rule analytics](/governance/rule-enforcement/analytics) for details.
## Change how rules are grouped
Use the grouping controls above the table to change how rules are organized:
| Grouping | What it shows |
| - | - |
| **Origin repo** | Grouped by where each rule comes from: its repository, then its source file. |
| **List** | Every rule in one flat list, with no grouping. |
## Anatomy of a rule
A rule consists of the following fields:
| Field | Description | Details |
| - | - | - |
| **Rule name** | Short, descriptive title summarizing the rule’s intent. | Shown in the table in the **Rules** tab and in code review findings. |
| **Rule content** | Enforcement description used during reviews. | Explains what to check and what behavior is expected. |
| **Examples** | Compliant and non-compliant code examples. | Displayed to developers when violations occur. |
| **Category** | Type of issue the rule addresses. | Security, Correctness, Quality, Reliability, Performance, Testability, Compliance, Accessibility, Observability, Architecture. |
| **Severity** | Priority level of a violation. | Error (action required), Warning (recommended), Recommendation (informational). |
| **Scope** | Where the rule is enforced. | **Global** by default, applying organization-wide, or limited to specific Git organizations, repositories, and optional path patterns. |
| **Source type** | The category of origin: how this rule was created or added. | User, Repository File, Qodo Library, Mined Pattern, Compliance File |
| **Source** | The exact location the rule came from. | A file path, URL, or identifier pointing to the original source. For a rule mined from the same pattern across multiple pull requests, shows the pull request count instead, linking to each contributing pull request. |
**Rule scope**
Scope defines where the rule is enforced. You can narrow the scope to limit enforcement:
* **Global** (default): applies the rule to all repositories across all Git organizations.
* **Git organization**: applies the rule to selected Git organizations.
* **Repository**: applies only to selected repositories.
* **Path patterns**: applies to specific directories or files within a repository. Path patterns are optional and can only be added after selecting a repository, and are especially useful for monorepos where different projects or services live under the same repository.
1. From **Rules**, click **Generate**.
2. Enter a short description of the rule’s intent.
3. Click **Generate rule**.
Example prompts:
* "Disallow `console.log` in production builds"
* "Avoid SQL string concatenation with user input"
