Customization

​

Making Diamond work for your team

Diamond's customization interface

​

Exclusions: Specifying what Diamond should ignore

• 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

### Bad example: Overly broad exclusion

Don't suggest performance improvements.

• This is too broad and would miss legitimate performance issues. The rule could be rewritten instead as:

Do not suggest performance optimizations for code in the /scripts directory - these are one-time utility scripts.

### Good example: Language-specific syntax exclusion

Do not comment on missing "return" keywords in Kotlin single-expression functions. This is valid Kotlin syntax.

1. Go to the Diamond settings page
2. Click on Workspace Settings
3. Create and save your exclusions

​

Custom rules: Teaching Diamond your standards

• 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

• Language-specific style guides (JavaScript, Python, Go, etc.)
• Security best practices
• Performance optimization guidelines
• Accessibility standards

​

Best practices for writing custom rules

• Use this format: Rule → Bad examples → Good examples → Reasoning
• 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

• 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

• 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

### Bad example 1: Vague database rule

Rule: Don't make breaking changes to database fields. When dropping or adding fields could cause issues, flag them in review.

• 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.

### Bad example 2: Unclear CSS class naming rule

Always comment on color values like #FF0000 being used in stylesheets. Don't comment on utility classes like bg-red-500 or text-primary.

• 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 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:**
```js
app.use((err, req, res, next) => {
  res.status(500).json({ error: err.stack });
});
```

**Good example:**
```js
app.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.

### 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.

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

• 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

# 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

• 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

​

PR-level filtering for Enterprise organizations

• 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

• 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