> ## Documentation Index > Fetch the complete documentation index at: https://autter.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Create a custom rule > Turn an existing team standard into a clear Autter review rule and roll it out safely. Use custom rules for standards your team already expects reviewers to enforce. Autter accepts these standards in natural language and applies them during review. ## Before you begin Choose a rule that is: * repeated across several pull requests * visible from code or repository context * specific enough to produce a pass or fail decision * important enough to justify reviewer attention ## Create the rule Start with a pull request comment that explains the standard and why it matters. Name the files, modules, or behavior the rule applies to. Use one direct sentence. Avoid combining security, style, and architecture requirements in one rule. Include legitimate exceptions in the rule wording so Autter does not flag them repeatedly. Open your organization's rule settings, enter the natural-language rule, and apply it to a small repository set. Open a representative pull request. Review both true findings and false positives before expanding the rule. Placeholder showing a natural-language custom rule and repository scope in Autter ## Example rules ### Security > Account-scoped API handlers must verify the authenticated account owns the requested resource before reading or changing it. ### Reliability > Payment state transitions must be idempotent and include a test for repeated webhook delivery. ### Architecture > HTTP controllers must call application services instead of importing the database client directly. ### Frontend consistency > UI colors must use design system tokens. Raw hexadecimal, RGB, and named color values are not allowed outside the theme package. ## Evaluate rule quality A rule is ready for broader use when: * findings point to the relevant code * the explanation tells the author what to change * approved patterns are not flagged * exceptions are rare and understandable * maintainers agree that the rule represents team policy Learn how to write focused and testable rules. See where rule findings appear in the review workflow.