Drixy Rules
Define, inherit, and preview custom review policies that Drixy enforces on every pull request.
Drixy rules are your team's review policies expressed as code. They range from deterministic AST matchers to natural-language guidelines the AI reviewer applies to every PR.
Rule scopes
Rules exist at three levels and inherit downward:
- Organization (global) — applies to every connected repository. Ideal for security baselines like
no-hardcoded-secrets. - Repository — enabled per repository from the dashboard or committed as markdown in the repo.
- Library — curated community best practices you can opt into with one click.
A repository-level rule can override severity or disable an inherited rule entirely. Inheritance is visible in the dashboard under Rules → Inheritance, so you always know which rule fired from where.
Anatomy of a rule
Rules are YAML. A deterministic rule targets AST patterns and attaches a message the reviewer posts on violation:
version: 1
rule:
id: sec-001
name: enforce-parameterized-sql
severity: critical
description: Never use string formatting or concatenation in database queries
match:
ast_call:
- "db.Query($QUERY)"
- "db.Exec($QUERY)"
where:
$QUERY: "binary_expression(op='+', type='string') | template_string"
message: "Critical SQL Injection risk detected. Always use parameterized queries (e.g. $1, ?, :param)."
Key fields:
| Field | Purpose |
|---|---|
id | Stable identifier used for suppression comments and metrics |
severity | critical, warning, or info — controls merge blocking |
match | AST patterns, entropy thresholds, or regex anchors |
message | The inline comment Drixy posts on violation |
Match against structure, not text: ast_call matches call targets and argument shapes, so the rule fires regardless of whitespace, variable names, or formatting your team's linter rewrites.
Categories in the catalog
The built-in catalog ships 13 rules across five categories:
- Security — parameterized SQL, hardcoded secrets (entropy + token regexes), injection-prone eval
- Architecture — multi-tenant query scoping (
tenant_id/organization_idfilters), layering boundaries - Performance — unbounded goroutine/async spawns, N+1 query shapes in loops
- Reliability — error swallowing, missing timeouts on outbound calls
- Code Style — formatting-independent conventions enforced by AST shape
Browse the full catalog with ready-to-paste YAML in the dashboard under Rules → Library, or via scandrix rules list in the CLI.
Dry Run previews
Before enforcing a rule change, run a Dry Run: the rule is evaluated against recent historical PRs and you see exactly which comments would have fired.
Edit or create the rule
Change severity, narrow a match, or add a new rule.
Run Dry Run
Click Dry Run in the dashboard (or scandrix rules dry-run <id> --since 30d).
Review the diff of comments
ScanDrix shows would-be findings per historical PR, with a false-positive rate for the change.
Promote
Happy with the signal? Promote the rule to active. Otherwise keep iterating — Dry Runs never touch live PRs.
Suppressing a single finding
Devs can silence a specific finding inline without disabling the rule:
/scandrix ignore sec-001 --reason "sanitize() applied upstream"
Suppressions are recorded in audit logs with author and reason — useful for SOC 2 evidence.
Feedback that sticks
Marking a suggestion helpful or not applicable on the PR is recorded per rule. Rules that repeatedly generate rejected findings are surfaced for tuning, so your rule set converges on your team's actual standards over time.