> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sourcery.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Write review rules

Most teams already have the raw material for review rules written down somewhere. A style guide, the conventions section of an engineering handbook, a pull request checklist, or just the three things you find yourself repeating in review every week. A review rule takes one of those, states it in plain language, and scopes it to the files it applies to.

Rules live on the **Review rules** tab of [**Review Settings**](https://app.sourcery.ai/dashboard/review-settings). They're available on all plans, and were previously called custom rules.

## Write a rule


    <Step title="Open the Review rules tab">
        Go to [**Review Settings**](https://app.sourcery.ai/dashboard/review-settings) and open the
        **Review rules** tab.
    </Step>

    <Step title="Set the path patterns">
        Add one or more globs under **Path patterns**, such as `src/api/**`. The rule applies only to
        files that match. Not sure how narrow to go? Leave it broad to apply everywhere.
    </Step>

    <Step title="Write the rule">
        Describe what Sourcery should check in the **Rule** field, which takes up to 3,000
        characters of free-form text. Be specific about what good and bad look like.
    </Step>



## How a rule changes a review

Sourcery checks the rule against every changed file its path patterns match. Where the code falls short, you get an ordinary inline comment on the line in question, carrying the same `type (area):` prefix as the rest of the review, with the rule quoted underneath so you can tell which one produced it.

A rule adds to a review rather than narrowing it. Sourcery still raises the bugs and issues it would have raised on those files anyway, and a rule only ever looks at what the pull request changes, not the rest of the repository.

## Example rules

### From your style guide

**Path patterns**: `**`

> Every new public function needs a docstring that explains its purpose. Flag any new public function without one.

### From your naming conventions

**Path patterns**: `src/**/*.tsx`

> Custom React hooks must be named with a `use` prefix and live in `src/hooks`. Flag any hook declared elsewhere or named without the prefix.

### From your architecture rules

**Path patterns**: `src/api/**`

> Endpoints must validate request input before using it. Flag any handler that reads request data without validating it first, and suggest the validation to add.

### From a migration in flight

**Path patterns**: `**/*.py`

> We are migrating from `requests` to `httpx`. Flag any new code that imports `requests` and suggest the `httpx` equivalent.

Each one says what to flag and what you want instead, which is what separates a rule Sourcery can act on from a sentence of good intentions.

> Review rules apply only to code review. The security scanners run fixed rule sets and are not
>     affected by your review rules.

## What's next