Skip to main content
VectorLint reviews your content by sending it to a large language model (LLM) along with a structured prompt that defines your quality criteria. The LLM acts as a judge, reading your content, applying the criteria, and returning findings. VectorLint then filters those findings through a deterministic pipeline before surfacing violations in the CLI. If you haven’t run your first review yet, start with the Quickstart. This page is for understanding the architecture behind what you’re running.

​
The review pipeline

Every time you run vectorlint doc.md, three things happen in sequence.

​
1. Rule resolution

VectorLint reads your .vectorlint.ini to determine which rule packs apply to the file. It loads those rule files, prepends the contents of VECTORLINT.md (if present) to each rule’s system prompt, and assembles the review context. If no .vectorlint.ini exists, VectorLint detects VECTORLINT.md and creates a synthetic “Style Guide Compliance” rule automatically. This is the zero-config path: the fastest way to get from nothing to a working review without writing any rule pack files.

​
2. LLM review

VectorLint sends your content to the configured LLM provider with each rule’s prompt. Depending on the rule type, the model returns either:
  • A list of specific violations (check rules): for countable errors like grammar mistakes or banned terms
  • A scored rubric (judge rules): for quality dimensions like tone, clarity, or technical accuracy rated on a 1–4 scale
Rules run concurrently up to the Concurrency limit set in .vectorlint.ini.

​
3. Filtering

Raw model output contains noise: potential violations that don’t hold up under scrutiny. VectorLint reduces false positives through a two-phase filtering process:
  1. Candidate generation: the model returns all potential violations, each tagged with required fields: rule support, exact evidence, context support, plausible non-violation, and fix quality.
  2. Deterministic surfacing: VectorLint applies a strict filter and only surfaces violations that pass all required gates.
The CLI output is intentionally stricter than raw model candidates with fewer results and higher confidence. You can tune how aggressively the filter operates with CONFIDENCE_THRESHOLD (default: 0.75). Lower values surface more findings with higher recall; higher values surface fewer findings with higher precision. See Configuring LLM providers for details.

​
Scoring

VectorLint scores each document using one of two methods, depending on what the rule asks the LLM to do. Density scoring applies when a rule counts discrete issues. It calculates error density (violations per 100 words) so a single error in a short document weighs more than the same error in a long one. This normalizes quality assessment across documents of any length. Rubric scoring applies when a rule rates quality on a spectrum. It normalizes the LLM’s 1–4 rating to a 1–10 scale and computes a weighted average across all criteria. Criteria weights reflect your real-world priorities. Technical accuracy might carry a weight of 40 while SEO carries a weight of 10. See Scoring for the full scoring reference.

​
Two ways to define quality

VectorLint gives you two complementary tools for expressing your content standards:
  • VECTORLINT.md: plain-language style instructions that apply globally to every review. The fastest path to useful output: no rule files, no configuration syntax, just plain English instructions that the LLM uses as context for every review.
  • Rule pack files: structured rules for specific, measurable standards with weighted scoring criteria. Use these when you need reproducible, auditable results on a particular dimension of quality.
The two work together: VECTORLINT.md sets the baseline context, and rule pack files enforce specific criteria on top of it. See Defining your style rules for how to create both.

​
Next steps