AI Code Review

Boltise reviews your changes before you push them — grounded in the same Code Graph, security audit, and static analysis engines the IDE already runs, not a raw diff pasted into a chatbot.

Running a review

Open AI Code Review from the command palette (Ctrl+Shift+P → “AI Code Review”), or the Editor tab bar once opened. Pick a scope:

• Unstaged — everything changed in your working tree.
• Staged — what’s staged for the next commit.
• Branch — diff between a base branch and a compare branch (defaults to HEAD), the same range GitHub/GitLab would show for a PR.

Click Run Review. For each changed .lua file, Boltise computes a symbol-level delta (which functions/handlers/exports were added, removed, or modified) and runs the resource’s security audit, unused-code analysis, and refactor-suggestion scanners — the same ones behind the Code Graph panel — scoped to just the files you touched. Those findings, plus the raw diff, are handed to the AI to explain and prioritize. Non-Lua changed files (JS/HTML/CSS/cfg/SQL) still get reviewed from the raw diff, without the symbol-level pass.

If no AI provider is configured, the review still runs — you get the scanner findings without AI commentary, rather than an error.

PR descriptions

Generate PR Description (branch scope) produces a markdown body: a short AI-written summary from your commit messages and symbol delta, lists of symbols added/removed/modified, and suggested reviewers (from git blame on the changed files). If your repo has a .github/PULL_REQUEST_TEMPLATE.md or a GitLab merge request template, it’s detected and your generated sections are appended below it rather than replacing it. Copy the result with the clipboard button.

Custom rules

Drop JSON files into .boltise/rules/ at your project root to add project-specific checks that run alongside the built-in scanners — no TypeScript required, hot-reloaded on save. Each file holds one rule object or an array of rules.

Two rule kinds:

regex — matched against raw file source, line by line:

{
  "id": "todo-fixme",
  "kind": "regex",
  "pattern": "\\b(TODO|FIXME|XXX)\\b",
  "flags": "i",
  "filePattern": "*.lua",
  "severity": "info",
  "message": "Left-over TODO/FIXME/XXX marker."
}

graph-query — matched against the parsed Code Graph for the resource (symbol kind, name, span length, edge presence):

{
  "id": "long-function",
  "kind": "graph-query",
  "symbolKind": "function",
  "maxSpanLines": 150,
  "severity": "info",
  "message": "Function is over 150 lines — consider splitting it up."
}

graph-query fields (all optional, combined with AND): symbolKind (e.g. function, event_handler, command, export, tick_loop), nameMatches (regex against the symbol name), requireIncomingEdgeKind / requireOutgoingEdgeKind (flag symbols missing an edge of that kind — e.g. net, export_call, db), maxSpanLines (flag symbols longer than N lines). A rule with none of those conditions flags every symbol matching symbolKind/nameMatches.

severity is critical, warning, or info on both rule kinds. Malformed rules (bad JSON, invalid regex, missing fields) are skipped with a console warning rather than breaking the review for everything else.

Ten ready-to-copy examples — covering both rule kinds, secrets, SQL concatenation, sensitive command/event names, and long functions — ship with Boltise. Copy any of them into .boltise/rules/ in your project to enable it.

Scope and limits

Symbol-level diffing and scanner intersection currently cover .lua files only (parser limitation — this matches the rest of the Code Graph subsystem). Reviews are capped at 30 changed files and roughly 50,000 characters of diff/context sent to the model per review, to keep requests bounded; large reviews note that they were truncated.

A GitHub Action that runs the same pipeline in CI on every PR — without Boltise installed — is planned but not yet built.