Configuration
Prelint works without any configuration. Install the GitHub App, and every PR gets reviewed. Add a prelint.json to your repository root when you want to exclude files, add custom rules, or control what context the review engine sees.
Quick start
Create a prelint.json file in your repository root:
{
"version": 1,
"exclude_authors": ["dependabot[bot]", "renovate[bot]"]
}That's it. Prelint indexes markdown files in your repo automatically and reviews every PR.
Configuration priority
Settings are merged from multiple sources. Higher-priority sources override lower ones:
- Built-in defaults: sensible starting configuration.
- Organization settings: set in the Prelint dashboard for all repos.
- Project settings: scoped to a project in the dashboard.
- Repository settings: set in the dashboard for a specific repo.
prelint.json: highest priority. Lives in the repo, versioned with your code.
Using prelint.json means your configuration is reviewed in PRs alongside your code. Teams can discuss and approve config changes like any other code change.
Full schema reference
| Property | Type | Default | Description |
|---|---|---|---|
| version | number | 1 | Schema version. Always set to 1. |
| exclude_authors | string[] | ["dependabot[bot]", "renovate[bot]", "github-actions[bot]", "snyk-bot"] | PR authors to skip. Supports GitHub bot format. |
| ignore_patterns | string[] | [] | Glob patterns for files to ignore in reviews. |
| rules | Rule[] | [] | Custom review rules. See Rules section below. |
| context_files | string[] | [] | Additional files to include as review context. |
| output.comments | boolean | true | Post inline comments on the PR diff. |
| output.check_run | boolean | true | Create a GitHub check run with review summary. |
Ignore patterns
Use glob syntax to exclude files from reviews. Patterns are matched against the file path relative to the repository root.
{
"ignore_patterns": [
"docs/**",
"**/*.test.ts",
"migrations/**",
"*.generated.ts",
"!docs/api/**"
]
}Built-in exclusions (always ignored):
*.lock,*-lock.*: lock filesvendor/**,node_modules/**: vendored dependencies*.min.js,*.min.css: minified assets*.png,*.jpg,*.gif,*.svg,*.ico: images*.woff,*.woff2,*.ttf,*.eot: fonts
Prefix a pattern with ! to negate it (force-include a file that would otherwise be ignored).
Rules
Custom rules let you enforce project-specific requirements beyond what specs cover. Each rule has a name and a description that the review engine uses.
{
"rules": [
{
"name": "No direct database queries in handlers",
"description": "All database access must go through the repository layer. Handler functions should not import or use database clients directly."
},
{
"name": "Feature flags for new endpoints",
"description": "New API endpoints must be wrapped in a feature flag. Use the featureFlags.isEnabled() check before executing endpoint logic."
}
]
}Rules are included in the review context alongside specs. The review engine evaluates every diff change against all active rules.
Context files
Context files provide additional information to the review engine without being formal specs. Use them for:
- API documentation that the code should match
- Database schemas that inform business logic
- Design system guidelines for frontend code
- Third-party integration docs that constrain implementation
{
"context_files": [
"docs/api-reference.md",
"docs/database-schema.md",
"ARCHITECTURE.md"
]
}Context files differ from specs: specs define what should be built, context files provide background information that helps the review engine understand your codebase.
Complete example
{
"version": 1,
"exclude_authors": [
"dependabot[bot]",
"renovate[bot]"
],
"ignore_patterns": [
"docs/**",
"**/*.test.ts",
"**/*.spec.ts",
"migrations/**"
],
"rules": [
{
"name": "Repository pattern",
"description": "All database access must use the repository pattern. No direct ORM calls in service or handler files."
}
],
"context_files": [
"ARCHITECTURE.md",
"docs/api-reference.md"
],
"output": {
"comments": true,
"check_run": true
}
}