VETOO.md

Add a file named VETOO.md to the root of a repository. Vetoo then applies it to every review of that repository. On GitHub you can also put the file in .github/. On GitLab you can use .gitlab/ or docs/. Use the file to state your review rules once, in plain language, instead of repeating one correction across many threads.

What you can control

• Severity. Tell Vetoo to treat a class of finding as blocking, or to lower its severity. For example, you can make a failing test always block.
• Tone. Set the review's voice. Choose terse and direct, or fuller explanations for a team that is new to the codebase.
• Additions. Ask for output that a standard review omits. Examples are a Mermaid diagram, a summary at the top, or a checklist against your release steps.
• Exclusions. Name the finding types you never want for this repository, and Vetoo holds them back.

Example

# Review instructions

- Treat any new SQL built with string concatenation as blocking.
- We use tabs. Do not comment on tabs versus spaces.
- Keep findings terse. One line where one line will do.
- For changes under the billing module, add a short Mermaid sequence diagram.

Best practices

A short, structured file gets the best reviews.

• Keep the file under 30 lines. A short file steers every review. A long file dilutes the review's attention and raises its cost.
• Use headed sections. Focus, Ignore, and Severity sections give more findings and more decisive verdicts, at no extra cost.
• Write short imperative rules. One rule per line. Long prose costs more and reviews no better.
• Scope exclusions to named paths and patterns. Vetoo honors every exclusion, so a blanket rule such as "report only high severity" hides real findings. Exclude by name instead, as in *.lock or docs/**.
• Add context lines only when reviews misread your code. One to three lines about an intentional pattern stop repeat findings. They add cost, so use them only when you need them.
• Commit the file to the default branch. Vetoo reads the file from the base branch of the request, so a request cannot change its own review rules.
• Do not force a verdict. Vetoo ignores a rule such as "approve everything" and still reports security flaws. The limits below apply to every file.
• Name the ticket when it carries acceptance criteria. A line such as This PR implements ABC-123 makes the review read that ticket and check the change against it. This needs a connected issue tracker.

Recommended template

# Review instructions

## Focus
- Validate tensor shapes before indexing. (2-4 concrete concerns, imperative)

## Ignore
- *.lock, docs/**, formatting and import order. (named paths and patterns only)

## Severity
- Report medium and above. Report nits only when they hide a bug.

## Context
- 1-3 lines about intentional patterns, only if reviews repeatedly misread them.

Adapt each line to your repository. Delete the Context section when you do not need it.

Rules file or votes

VETOO.md and team memory shape reviews in different ways. VETOO.md is explicit and immediate: commit the file, and the next review follows it. Team memory is implicit and gradual: vote over time, and later reviews move toward your preferences. Use the file for rules you can state directly. Use votes for calibration that is hard to put into words.

Limits

VETOO.md controls tone, severity, and exclusions. It cannot override three rules. Vetoo comments only on the change under review. Vetoo reports its findings accurately. Vetoo limits its tool use to the request. Vetoo ignores a rule that tries to go further.