Generic AI advice
Without a codebase-specific rule, general-purpose advice can miss internal dependency boundaries, mandatory audit logging, or required exception handling.
Outcome: Valid code can still violate team intent.
Policy as Code / Pull request guardrails
Turn team standards into version-controlled PR rules.
Write your review policy in Markdown. ScanDrix evaluates the changed code against that rule and returns a focused, actionable review on the pull request.
- Reviewable in Git
- Scoped by path and language
- Written for humans
- 01
Markdown rule
State the standard in a reviewable file.
- 02
AST-aware analysis
Match the changed code to the rule scope.
- 03
PR comment
Explain the finding and the path forward.
01 — The mental model
Review intent becomes a reviewable artifact.
Policy as Code Review means writing an engineering standard as a Markdown rule, scoping where it applies, and evaluating changed code against its instructions during pull-request review.
A general checklist reminds a reviewer what to remember. A broad prompt gives a model room to interpret. A policy rule is narrower: it pairs an explicit standard with a path, language, severity, and review behavior—so the team can inspect, revise, and enforce it through Git.
02 — Why codify it
The gap is context, not syntax.
The risk starts when a team’s standards cannot be expressed, scoped, and checked consistently at the point of change.
Syntax-only checking
Linters and pattern scanners are precise for known syntax. Requirements that depend on intent or cross-file context need another layer.
Outcome: Known patterns pass while policy gaps remain.
Knowledge in one reviewer’s head
Standards held by a few people are difficult to apply consistently, repeat, and change safely as the codebase evolves.
Outcome: Reviews vary and important context stays hidden.
03 — Workflow
From team convention to pull-request feedback.
The rule is the durable source. Automated review makes the repeatable check; human reviewers still own judgment and exceptions.
- 01
Author the rule
Write the standard as Markdown, with frontmatter for the parts that control when and how it runs.
- 02
Set the scope
Limit the rule by file path, language, review scope, and the minimum severity worth reporting.
- 03
Analyze the diff
ScanDrix evaluates changed code against the rule, using structural analysis for known code shapes and additional reasoning when context matters.
- 04
Report the result
The review connects the finding to the rule, points to the changed code, and provides remediation guidance when it can be supported.
04 — Rule explorer
Inspect a rule before you enforce it.
Choose a sample to see the Markdown source beside a simulated pull-request finding and code remediation. Every example on this page is illustrative.
Selected rule
Prevent raw SQL concatenation
Security
Markdown rule
.scandrix/rules/prevent-raw-sql.md
---
title: "Enforce parameterized SQL queries"
scope: "file"
path: ["src/repositories/**/*.ts"]
severity_min: "critical"
languages: ["typescript"]
enabled: true
---
## Instructions
Flag database queries built with string interpolation or concatenation
when they include request data. Require parameterized queries or
the repository's query builder.Simulated PR review
src/repositories/user-repo.ts:48
Example finding
Dynamic SQL is built from request input. The value must be passed to the database client as a parameter instead of interpolated into the query string.
Suggested fix: Keep the SQL text constant and pass untrusted values separately to the database client.
Illustrative code remediation
- const query = `SELECT * FROM users WHERE id = '${req.query.id}'`;
+ const query = 'SELECT * FROM users WHERE id = $1';
+ await db.query(query, [req.query.id]);Showing Prevent raw SQL concatenation.
05 — Evaluation model
Structure when it is known. Context when it is needed.
ScanDrix uses a hybrid model rather than asking one mechanism to solve every policy problem. The rule defines the boundary; analysis and reasoning help apply it to the changed code.
Match known structure
For explicit syntax and code-shape requirements, AST-aware analysis is more reliable than matching raw text alone.
Keep the rule in scope
Path, language, and severity settings narrow evaluation to the changes and findings the rule is meant to govern.
Reason with context
When intent crosses files or depends on domain behavior, AI reasoning adds context to the structural signals already available.
Make the review actionable
A useful finding identifies the changed location, explains the connection to the rule, and suggests a concrete fix when one is available.
06 — Rule anatomy
A small contract for review behavior.
The instruction stays in Markdown. YAML frontmatter supplies the structured fields used to scope and run it.
- title
- string · required
The human-readable name used in the rule and its review output.
Example:
"Enforce parameterized SQL queries"- scope
- file | pr · required
Controls whether the rule is evaluated against an individual changed file or pull-request-wide context.
Example:
"file"- path
- string[] · required
Glob patterns that limit the files where the rule applies.
Example:
["src/repositories/**/*.ts"]- severity_min
- critical | high | medium | low · required
The minimum finding severity the rule should report.
Example:
"high"- languages
- string[] · required
Programming languages the rule should evaluate.
Example:
["typescript", "javascript"]- enabled
- boolean · optional
Turns the rule on or off without removing its source.
Example:
true
Codify the rule your reviewers repeat.
Start with one enforceable standard, review how it behaves, then expand the policy as your team learns.