While Diamond will catch bugs out of the box, you can customize its behavior to better match your team’s specific needs and coding standards. Diamond offers two primary customization options: Exclusions and Custom rules.
Comment exclusions allow you to specify situations where Diamond should not leave comments. This reduces noise and places Diamond’s focus on what matters most to your team.Common exclusion use cases:
Ignore generated code: Prevent extraneous comments on generated code from build artifacts, schemas, and other generated files.
Skip specific types of comments: Turn off categories of feedback that aren’t relevant to your team
Ignore certain repositories or directories: Focus Diamond’s attention where it matters most
Exclude specific patterns: Define patterns that Diamond should not flag (e.g., team-specific style conventions)
Make the language as targeted as possible by specifying the exact scope where the exclusion should apply. If an exclusion is written too broadly, then Diamond may not leave valid comments.Bad example:
Copy
Ask AI
### Bad example: Overly broad exclusionDon't suggest performance improvements.
Why is this bad?
This is too broad and would miss legitimate performance issues. The rule could be rewritten instead as:
Copy
Ask AI
Do not suggest performance optimizations for code in the /scripts directory - these are one-time utility scripts.
Good example:
Copy
Ask AI
### Good example: Language-specific syntax exclusionDo not comment on missing "return" keywords in Kotlin single-expression functions. This is valid Kotlin syntax.
Custom rules allow you to define explicit guidelines for Diamond to follow when reviewing your code. This is especially powerful for enforcing team-specific best practices.With custom rules, you can:
Define coding standards specific to your codebase
Implement architectural guidelines for your team
Enforce security or performance best practices
Ensure consistent patterns across your repositories
Diamond's custom rule interface
There are two ways to configure custom rules: custom prompts and file-based rules. Below is our recommendation for when each option is most appropriate.
File-based rules reference existing documentation in your repository using glob patterns. Use these sparingly when you have living documentation that changes frequently.When to use file-based rules:
Documentation maintained by other teams that changes regularly
Shared architectural decision records across repositories
Style guides that are actively updated
How they work:
Specify a glob pattern (e.g., docs/coding-style.md)
Diamond reads the file content from your repository
Security guidelines (authentication, data validation)
Framework-specific patterns (React hooks, API design)
What to avoid:
Overly broad rules (“write good code”)
Subjective preferences without clear reasoning
Complex architectural patterns that only sometimes apply
Bad examples:
Copy
Ask AI
### Bad example 1: Vague database ruleRule: Don't make breaking changes to database fields. When dropping or adding fields could cause issues, flag them in review.
Why is this bad?
Too vague. The rule needs to specify what types of field drops or additions would be considered breaking.
Not actionable. The rule should be specific, like: “Never drop a required field directly. Always make it nullable first and stop writing to it so that it is no longer used by the entity.”
No examples provided.
Copy
Ask AI
### Bad example 2: Unclear CSS class naming ruleAlways comment on color values like #FF0000 being used in stylesheets. Don't comment on utility classes like bg-red-500 or text-primary.
Why is this bad?
More context is needed. The rule should specify which files or frameworks this applies to (CSS files, styled-components, etc.).
This isn’t phrased as a rule. The rule should be stated clearly as “Never use hex color values directly, always use design system tokens instead.”
This prompt mixes custom rules and exclusions. The latter sentence is not necessary.
Good examples:
Copy
Ask AI
### Good example 1: Security rule with clear structure## Security Rules### Rule: Never expose detailed error messages**Rule:** Never expose detailed error messages that reveal stack traces or internal system details. In production environments, always return generic error messages to protect the system while logging full details internally for debugging.**Bad example:**```jsapp.use((err, req, res, next) => { res.status(500).json({ error: err.stack });});```**Good example:**```jsapp.use((err, req, res, next) => { res.status(500).json({ error: "Internal Server Error" });});```**Reasoning:** Revealing stack traces or internal error details can leak sensitive implementation information, making it easier for attackers to exploit vulnerabilities.
Copy
Ask AI
### Good example 2: Database rule with specific context## Database Rules### Rule: Use `text` instead of `varchar(n)` for new PostgreSQL columns**Rule:** When adding new string columns to TypeORM entities, always use `text` type instead of `varchar(n)` unless there's a specific business requirement for length constraints.**Good example:**```ts@Column({ type: 'text' })description: string;```**Bad example:**```ts@Column({ type: 'varchar', length: 255 })description: string;```**Reasoning:** PostgreSQL handles `text` and `varchar` identically in terms of performance, but `text` avoids arbitrary length limits that can cause issues as data grows.
Enterprise organizations have access to advanced PR-level filtering capabilities that provide granular control over when Diamond runs code reviews. This Enterprise-only feature allows you to configure Diamond to only analyze certain pull requests based on specific criteria.With PR-level filtering, you can control Diamond based on:
PR author: Run Diamond only for specific team members or external contributors
File paths: Analyze PRs only when certain files or directories are modified
PR labels: Trigger Diamond based on GitHub labels applied to pull requests
PR title and description: Filter based on text content in PR titles or descriptions
Parent branch: Run analysis based on target branch naming conventions
PR-level filtering provides Enterprise customers with flexibility to:
Control usage and costs: Optimize Diamond usage by focusing on the most important PRs
Focus analysis on critical PRs: Ensure Diamond reviews high-impact changes while skipping routine updates
Implement organization-specific review policies: Align Diamond’s behavior with your team’s development workflows and governance requirements
Once saved, Diamond will only run on new and updated pull requests that match the configured filters in Diamond-enabled repositories. Enterprise customers can configure these filters through the Diamond settings page, and organization admin permissions are required to modify the filters.