Skip to main content
This guide walks you through creating a rule pack file from scratch, connecting it to a file pattern, and writing rules that produce accurate, low-noise results. By the end you’ll have a working rule you can adapt for your own content standards.

​
Before you start

You’ll need a working VectorLint installation with an LLM provider configured. If you haven’t done that yet, complete Installation and Configuration first.

​
Step 1: Create your rules directory

VectorLint looks for rule packs in the directory specified by RulesPath in .vectorlint.ini. Create the directory structure: 
mkdir -p .github/rules/MyTeam
This creates a rule pack called MyTeam. Pack names come from subdirectory names inside RulesPath.

​
Step 2: Write the rule file

Create a new file at .github/rules/MyTeam/grammar-checker.md: 
---
id: GrammarChecker
name: Grammar Checker
evaluator: base
type: check
severity: error
---

Check this content for grammar issues, spelling errors, and punctuation mistakes.
Report any errors found with specific examples from the text.
That’s a complete, working rule. The YAML frontmatter configures how VectorLint handles the result. The Markdown body is the prompt sent to the LLM.

​
Step 3: Configure .vectorlint.ini

Open your .vectorlint.ini and add the RulesPath setting and a file pattern that runs your new pack: 
RulesPath=.github/rules

[**/*.md]
RunRules=MyTeam

​
Step 4: Run a review

Point VectorLint at any Markdown file: 
vectorlint doc.md
VectorLint sends the file content to your LLM with the GrammarChecker rule, filters the results for confidence, and prints any violations with their location and suggested fix. A clean file produces no output and exits with status 0. A file with violations prints each finding and exits with a non-zero status.

​
Writing effective rules

The Markdown body of your rule file is the instruction sent to the LLM. Specificity here directly determines review quality. A vague rule produces vague findings. Be explicit about what you’re looking for: 
# ❌ Vague
Check if the headline is good.

# ✅ Specific
You are a headline evaluator for developer blog posts. Assess whether the headline:

1. Clearly communicates a specific benefit to the reader
2. Uses natural, conversational language (avoid buzzwords like "leverage" or "unlock")
3. Creates curiosity without resorting to clickbait
Give the LLM domain context: 
## CONTEXT BANK

**Audience**: Software engineers, DevOps practitioners, and QA professionals who value:
- Technical precision over marketing language
- Practical examples over theory
- Direct answers over lengthy preambles
Use meaningful weights to reflect real-world importance. Scale them to signal what actually matters in your content workflow: 
criteria:
  - name: Technical Accuracy
    id: TechnicalAccuracy
    weight: 40       # Critical - factual errors erode trust
  - name: Readability
    id: Readability
    weight: 30       # Important - but recoverable in editing
  - name: SEO
    id: SEO
    weight: 10       # Nice to have

​
Next steps