​
Making Diamond work for your team

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.

Diamond's customization interface

​
Exclusions: Specifying what Diamond should ignore

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)

​
Best practices for writing exclusions

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. To set up exclusions:
  1. Go to the Diamond settings page
  2. Click on Workspace Settings
  3. Create and save your exclusions

​
Custom rules: Teaching Diamond your standards

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 provides templates for common rule sets to help you get started:
  • Language-specific style guides (JavaScript, Python, Go, etc.)
  • Security best practices
  • Performance optimization guidelines
  • Accessibility standards
The fastest way to see immediate value from custom rules is to directly paste in your organization’s existing coding guidelines or documentation. Diamond will automatically interpret these and apply them during code review.

​
Best practices for writing custom rules

Be explicit with your instructions
  • Use this format: Rule → Reasoning → Bad examples → Good examples
  • Keep rules focused and concise rather than creating one large rule with multiple concerns
  • Include up to 5 good and bad examples for clarity
  • Leverage Graphite’s built-in templates or existing resources as a starting point
Golden custom rule example 
Rule: Never expose detailed error messages that reveal stack traces or internal system details.
Reasoning: Revealing stack traces or internal error details can leak sensitive implementation information, making it easier for attackers to exploit vulnerabilities.
In production environments, always return generic error messages to protect the system while logging full details internally for debugging.

Bad example:
```
js
app.use((err, req, res, next) => {
  res.status(500).json({ error: err.stack });
});
```

Good example (production mode - generic error message):
```
js
app.use((err, req, res, next) => {
  res.status(500).json({ error: "Internal Server Error" });
});
```
For additional recommendations, see Anthropic’s suggestions for prompt engineering best practices. Focus on what works best
  • Prefer: Language-specific conventions, security guidelines, and framework patterns that almost always apply
  • Avoid: complex architectural patterns that sometimes apply in certain circumstances
  • Start with high-confidence, high-impact rules and iterate
Avoid common pitfalls
  • Don’t create overly broad or subjective rules
  • Ensure examples are clear and contrasting
  • Always explain the rationale behind each rule
  • Start small and gradually add more rules
To set up custom rules:
  1. Go to the Diamond settings page
  2. Scroll to the “Custom rules” section and click on “Create custom rule”
  3. Choose a template or add a custom prompt for your new rule
  4. Save your configuration

​
Excluding files from Diamond review

For large repositories, you may want to exclude certain files from Diamond’s analysis. This is useful for:
  • Data files that don’t need to be reviewed
  • Generated code that is automatically created by tools
  • Any files that would make a PR too big for Diamond to analyze
You can exclude files by marking them as generated files in your repository’s .gitattributes file: 
# Exclude specific files
docs/data.txt linguist-generated=true

# Exclude file types
*.csv linguist-generated=true
*.pb.go linguist-generated=true

# Exclude entire directories
data/* linguist-generated=true
generated/* linguist-generated=true
Files marked as linguist-generated will be:
  • Automatically collapsed in GitHub pull request views
  • Excluded from Diamond’s analysis when determining if a PR is too large
  • Skipped during Diamond’s code review process
For more information, see GitHub’s documentation on customizing how changed files appear on GitHub.

​
PR-level filtering for Enterprise organizations

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.