> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vectorlint.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Customizing style rules

> Write effective rules to enforce your content standards.

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](/installation) and [Configuration](/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:

```bash theme={null}
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`:

```markdown theme={null}
---
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:

```ini theme={null}
RulesPath=.github/rules

[**/*.md]
RunRules=MyTeam
```

## Step 4: Run a review

Point VectorLint at any Markdown file:

```bash theme={null}
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:**

```markdown theme={null}
# ❌ 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:**

```markdown theme={null}
## 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:

```yaml theme={null}
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

* [Defining your style rules](/style-guide) - full reference for rule anatomy, review modes, targeting, and examples
* [Project Configuration](/project-config) - control which rules run on which files
* [LLM Providers](/llm-providers) - switch providers or tune false-positive filtering