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
Collect a real example
Start with a pull request comment that explains the standard and why it matters.
State the requirement
Use one direct sentence. Avoid combining security, style, and architecture requirements in one rule.
Add exceptions
Include legitimate exceptions in the rule wording so Autter does not flag them repeatedly.
Create the rule in Autter
Open your organization’s rule settings, enter the natural-language rule, and apply it to a small repository set.
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
Rules reference
Learn how to write focused and testable rules.
Code review
See where rule findings appear in the review workflow.