Rules and Learnings

Rule design principles

• Prefer explicit outcomes over vague style preferences.
• Keep each rule focused on one engineering concern.
• Use examples in rule content when behavior is nuanced.

Global rules

• Apply to every connected repository.
• Best for cross-team standards such as security or architecture.
• Support optional file patterns to target code subsets.

Repository rules

• Apply only to a specific repository.
• Useful for framework-specific conventions or service-specific guard rails.
• Can coexist with global rules for layered behavior.

How rule resolution works

1. Global rules provide baseline review behavior.
2. Repository rules add local context for that codebase.
3. File patterns narrow scope to matching files only.
4. Inactive rules are ignored until re-enabled.

Learning extraction workflow

1. Trevyn posts a comment on a PR.
2. You reply with context, correction, or preference.
3. Trevyn extracts a reusable learning with source reference.
4. Active learnings influence future review suggestions.

Best practices

• Keep rule titles short and explicit.
• Write one concern per rule for easier evolution.
• Disable stale learnings instead of deleting immediately.
• Review active learnings monthly with your team.
• Promote repeated learnings into formal rules when stable.