.lgtm.yml — repo-level LGTM config
.lgtm.yml is the repo-level config file for LGTM. It lives at your repo root (or .github/lgtm.yml), is opt-in per repo, and lets maintainers override 9 pipeline behaviours: mute agents, skip paths, cap severity, auto-approve docs-only PRs, override severity by category, and more. The rules are enforced at the pipeline layer, not the prompt, so the LLM can't 'forget' them.
Why a repo-level config file at all?
AI code reviewers that only expose a dashboard eventually hit a wall: teammates disagree about what to flag, PRs from Dependabot flood the review queue with noise, and legacy directories get nagged forever. A checkbox in a dashboard fixes it for one person; a file committed to the repo fixes it for the entire team + CI + every branch protection rule that runs.
LGTM's .lgtm.yml file lives with the code and is versioned with the code. When you rename a legacy directory, the skip rule moves with it. When a new teammate opens their first PR, LGTM behaves the way the repo has always behaved — no dashboard onboarding required.
What you can put in it
Nine rule types cover the 80% of complaints teams file against AI reviewers: disabled_agents (turn off documentation on this repo), max_inline_comments (cap the review noise), paths[].skip (never review generated code / vendor / lockfiles), paths[].skip_agents (skip only readability in legacy dirs), paths[].max_severity (cap severity per path), suppress_categories (mute a whole vuln class), severity_overrides (bump sql-injection to critical globally), frameworks (override auto-detect), auto_approve_docs_only, and skip_lockfile_changes.
auto_approve_docs_only and skip_lockfile_changes are the two everyone wants: a PR that only touches .md files or only touches package-lock.json is approved immediately with no LLM call. Costs nothing, contributors get instant sign-off, Dependabot flows through the queue.
How LGTM enforces it (pipeline layer, not prompt)
The naïve approach — 'add these rules to the LLM's system prompt and hope' — breaks the first time the model drifts. LGTM parses .lgtm.yml with a Zod schema and applies the rules AFTER the six agents return their findings. suppress_categories filters at the code level. paths[].skip strips files BEFORE we fetch them from GitHub, so no LLM ever sees them. auto_approve_docs_only short-circuits the whole pipeline before any agent runs.
This matters because it means a new model release, a new prompt-injection payload, or a model that misinterprets the file's spec can never re-introduce a suppressed category. The pipeline is the ground truth. The LLM is a suggestion.
Invalid YAML never fails a review
Config files that fail the review are a footgun — a broken .lgtm.yml would silently start blocking every PR. LGTM instead falls back to defaults + posts a one-line warning on the PR review comment pointing at the exact error location. Fix the YAML, push again, the next review runs with the fixed rules.
The parse warning also surfaces in the per-repo Settings dashboard so it's visible even if no PR has run yet since the break.
Two ways to edit it
(a) Commit it yourself: create .lgtm.yml at your repo root, add rules, push, done. Same as any other config file. (b) Use the dashboard editor at Dashboard → Repositories → gear icon → .lgtm.yml tab. Pick any branch (auto-created if it doesn't exist), edit the YAML in the form, click Commit. The dashboard uses the GitHub App token to write the file for you.
Both paths write to the same file. There's no dashboard-only override state to drift from the committed truth — the file always wins.
See the full .lgtm.yml spec + examples
9 rule types · Zod-validated · pipeline-enforced
Go to the product pageFAQs
Do I have to create .lgtm.yml for LGTM to work?
No. The file is opt-in — LGTM reviews every repo with sensible defaults out of the box. Add .lgtm.yml only when a default annoys you.
What happens if the YAML is invalid?
The pipeline falls back to defaults and posts a one-line warning on the PR review comment pointing at the exact error. It never fails the review. Fix the file, push again, next review runs with the new rules.
Can I put .lgtm.yml in .github/ instead of the root?
Yes. LGTM checks the repo root first, then .github/lgtm.yml. If both exist, the root file wins.
Can I test my .lgtm.yml before pushing it?
The dashboard editor at Repositories → gear icon → .lgtm.yml tab loads the current file from any branch. You can iterate against a scratch branch, verify the pipeline behaves how you want on a test PR, then merge into main.
Does .lgtm.yml replace CLAUDE.md or AGENTS.md?
No — they're complementary. CLAUDE.md carries prose conventions the LLM tries to follow (naming rules, style guides). .lgtm.yml carries structured rules the pipeline enforces (skip these files, mute this agent). If both say something about the same finding, .lgtm.yml wins because it runs after the LLM.
Related across LGTM
Related terms
AI code review
AI code review uses large language models (and increasingly multi-agent pipelines) to review pull requests for bugs, security issues, performance regressions, readability, and style — automatically, on every PR, in 30-90 seconds.
Convention file (CLAUDE.md, AGENTS.md, .cursorrules, etc.)
A convention file is a repo-level Markdown document (CLAUDE.md, AGENTS.md, .cursorrules, .github/copilot-instructions.md, .windsurfrules, CONTRIBUTING.md) that tells AI assistants and reviewers how the repo prefers code to be written. LGTM ingests these and drops findings that contradict them.
LLM code review pipeline
An LLM code review pipeline is the end-to-end system that ingests a GitHub PR webhook, fetches the diff, gathers repo context, runs one or more LLM agents in parallel, synthesizes their outputs, and posts the result back to GitHub as a review with inline comments.