Prelint
Overview

How reviews work

The review pipeline#

1. Trigger. A pull request is opened, reopened, converted from draft, or updated with new commits. GitHub sends a webhook event to Prelint.

2. Prepare. Prelint validates the webhook, checks that the repository is connected, and confirms the author is not excluded. The diff is fetched and review context is assembled — product specifications, architecture decisions, and custom rules, prioritized within an 80K character budget.

3. Review. The review engine analyzes the diff against the assembled context, evaluating product alignment, decision compliance, spec violations, and business logic.

4. Validate. A second pass checks each finding for relevance. Findings that overlap with linter territory, rely on speculation, contradict documented context, or lack evidence from the diff are filtered out.

5. Post. Findings are posted as inline comments pinned to the lines that triggered them. A check run summary is created. Previous findings from earlier reviews on the same pull request resolve automatically.

What gets checked#

Layer What Prelint evaluates
Product alignment Does the code match what the product spec describes?
Decision compliance Do the changes follow documented architecture decisions?
Custom rules Are project-specific rules from prelint.json being followed?
Business logic Do calculations, workflows, and transformations match requirements?
Scope drift Does the pull request introduce changes outside its stated purpose?

Prelint does not check code style, formatting, type safety, or security vulnerabilities. ESLint, Prettier, and Snyk handle those. Prelint covers the product layer alongside them — see Product review vs code review for where the line sits.

What gets ignored#

Prelint skips files that rarely contain product-relevant changes:

  • Binary files: images, fonts, compiled assets
  • Generated code: protobuf output, OpenAPI clients, generator migrations
  • Lock files: package-lock.json, yarn.lock, pnpm-lock.yaml, Gemfile.lock
  • Vendored dependencies: vendor/, node_modules/
  • AI tool plumbing: hooks, skills, MCP configs. Instruction files like .cursorrules and CLAUDE.md are still reviewed normally.
  • Draft pull requests, until marked ready
  • Bot-authored pull requests from Dependabot, Renovate, GitHub Actions, and Snyk

Customize ignore patterns with glob syntax in prelint.json.

Review context priority#

Context is assembled within an 80K character budget, loaded in priority order:

  1. Organization-level specs — product vision, company-wide standards, cross-project rules set in the dashboard
  2. Project-level specs — requirements and decisions scoped to a project
  3. Repository-level context — specifications and decisions stored in the repo itself, indexed automatically
  4. Documentation — additional markdown files, READMEs, and other docs discovered in the repository

Higher-priority context is always included first, so organization rules survive a crowded budget.

Powered by Docsbook